Hello,

The QEMU PowerNV machine emulates a baremetal OpenPOWER system and
acts as an hypervisor (L0). Supporting emulation of KVM to run guests
(L1) requires a few more extensions, among which guest support for the
XIVE interrupt controller on POWER9 processor.

The following changes add new per-CPU PowerNV machines and extend the
XIVE models with the new XiveFabric and XivePresenter interfaces to
provide support for XIVE escalations and interrupt resend. This
mechanism is used by XIVE to notify the hypervisor that a vCPU is not
dispatched on a HW thread. Tested on a QEMU PowerNV machine and a
simple QEMU pseries guest doing network on a local bridge.

The XIVE interrupt controller offers a way to increase the XIVE
resources per chip by configuring multiple XIVE blocks on a chip. This
is not currently supported by the model. However, some configurations,
such as OPAL/skiboot, use one block-per-chip configuration with some
optimizations. One of them is to override the hardwired chip ID by the
block id in the PowerBUS operations and for CAM line compares. This
patchset improves the support for this setup. Tested with 4 chips.

A series from Suraj adding guest support in the Radix MMU model of the
QEMU PowerNV machine is still required and will be send later. The
whole patchset can be found under :

  https://github.com/legoater/qemu/tree/powernv-4.1

Thanks,

C.

Changes since v2:

 - introduced the XiveFabric and XivePresenter interfaces
 - removed the need of a XiveRouter pointer under XiveTCTX

Changes since v1:

 - minor extra fixes 
 - split the escalation support in different patches
 - kept the XiveRouter type for XiveTCTX back pointer (will address
   this in P10)
 - removed pnv_xive_vst_size(). Really broken on indirect tables.
 - improved the dump of the NVT table
 - introduce pnv_xive_get_block_id()


Cédric Le Goater (18):
  ppc/pnv: Introduce PowerNV machines with fixed CPU models
  tests/boot-serial-test: add support for all the PowerNV machines
  ppc/xive: Introduce the XiveFabric and XivePresenter interfaces
  ppc/pnv: Implement the XiveFabric and XivePresenter interfaces
  ppc/spapr: Implement the XiveFabric and XivePresenter interfaces
  ppc/xive: Use the XiveFabric and XivePresenter interfaces
  ppc/xive: Extend the TIMA operation with a XivePresenter parameter
  ppc/pnv: Clarify how the TIMA is accessed on a multichip system
  ppc/xive: Move the TIMA operations to the controller model
  ppc/xive: Introduce a xive_tctx_ipb_update() helper
  ppc/xive: Synthesize interrupt from the saved IPB in the NVT
  ppc/pnv: Remove pnv_xive_vst_size() routine
  ppc/pnv: Dump the XIVE NVT table
  ppc/pnv: Skip empty slots of the XIVE NVT table
  ppc/pnv: Introduce a pnv_xive_block_id() helper
  ppc/pnv: Extend XivePresenter with a get_block_id() handler
  ppc/pnv: Quiesce some XIVE errors
  ppc/xive: Introduce a xive_os_cam_decode() helper

 include/hw/ppc/pnv.h       |  13 ++
 include/hw/ppc/pnv_xive.h  |   3 -
 include/hw/ppc/spapr_irq.h |   6 +
 include/hw/ppc/xive.h      |  71 ++++++--
 include/hw/ppc/xive_regs.h |  24 +++
 hw/intc/pnv_xive.c         | 356 ++++++++++++++++++++++++-------------
 hw/intc/spapr_xive.c       |  80 ++++++++-
 hw/intc/xive.c             | 319 ++++++++++++++++++---------------
 hw/ppc/pnv.c               | 102 ++++++++++-
 hw/ppc/spapr.c             |  34 ++++
 hw/ppc/spapr_irq.c         |  25 +++
 tests/boot-serial-test.c   |   3 +-
 12 files changed, 743 insertions(+), 293 deletions(-)

-- 
2.21.0

On 31/07/2019 16:12, Cédric Le Goater wrote:
> Hello,
> 
> The QEMU PowerNV machine emulates a baremetal OpenPOWER system and
> acts as an hypervisor (L0). Supporting emulation of KVM to run guests
> (L1) requires a few more extensions, among which guest support for the
> XIVE interrupt controller on POWER9 processor.
> 
> The following changes add new per-CPU PowerNV machines and extend the
> XIVE models with the new XiveFabric and XivePresenter interfaces to
> provide support for XIVE escalations and interrupt resend. This
> mechanism is used by XIVE to notify the hypervisor that a vCPU is not
> dispatched on a HW thread. Tested on a QEMU PowerNV machine and a
> simple QEMU pseries guest doing network on a local bridge.
> 
> The XIVE interrupt controller offers a way to increase the XIVE
> resources per chip by configuring multiple XIVE blocks on a chip. This
> is not currently supported by the model. However, some configurations,
> such as OPAL/skiboot, use one block-per-chip configuration with some
> optimizations. One of them is to override the hardwired chip ID by the
> block id in the PowerBUS operations and for CAM line compares. This
> patchset improves the support for this setup. Tested with 4 chips.

David,

Do you want me to resend this patchset ? or you just didn't have time
to look at it ?  

Patch 16 has changed a little since. The get_block_id() handler has 
moved to the XiveRouterClass.


Thanks,

Thanks,

C.

On Tue, Sep 17, 2019 at 01:54:24PM +0200, Cédric Le Goater wrote:
> On 31/07/2019 16:12, Cédric Le Goater wrote:
> > Hello,
> > 
> > The QEMU PowerNV machine emulates a baremetal OpenPOWER system and
> > acts as an hypervisor (L0). Supporting emulation of KVM to run guests
> > (L1) requires a few more extensions, among which guest support for the
> > XIVE interrupt controller on POWER9 processor.
> > 
> > The following changes add new per-CPU PowerNV machines and extend the
> > XIVE models with the new XiveFabric and XivePresenter interfaces to
> > provide support for XIVE escalations and interrupt resend. This
> > mechanism is used by XIVE to notify the hypervisor that a vCPU is not
> > dispatched on a HW thread. Tested on a QEMU PowerNV machine and a
> > simple QEMU pseries guest doing network on a local bridge.
> > 
> > The XIVE interrupt controller offers a way to increase the XIVE
> > resources per chip by configuring multiple XIVE blocks on a chip. This
> > is not currently supported by the model. However, some configurations,
> > such as OPAL/skiboot, use one block-per-chip configuration with some
> > optimizations. One of them is to override the hardwired chip ID by the
> > block id in the PowerBUS operations and for CAM line compares. This
> > patchset improves the support for this setup. Tested with 4 chips.
> 
> David,
> 
> Do you want me to resend this patchset ? or you just didn't have time
> to look at it ?  

Mostly, I just haven't had time.  I'm also finding the patches pretty
difficult to read and review.  I don't think that's an indication
they're bad, just that what they're doing is necessarily complex, but
it's still made it hard to tackle them.

> Patch 16 has changed a little since. The get_block_id() handler has 
> moved to the XiveRouterClass.

You, might as well repost, so I'm looking at the latest stuff.  I
can't promise I'll be able to look at the new set terribly soon
though.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

On 18/09/2019 07:44, David Gibson wrote:
> On Tue, Sep 17, 2019 at 01:54:24PM +0200, Cédric Le Goater wrote:
>> On 31/07/2019 16:12, Cédric Le Goater wrote:
>>> Hello,
>>>
>>> The QEMU PowerNV machine emulates a baremetal OpenPOWER system and
>>> acts as an hypervisor (L0). Supporting emulation of KVM to run guests
>>> (L1) requires a few more extensions, among which guest support for the
>>> XIVE interrupt controller on POWER9 processor.
>>>
>>> The following changes add new per-CPU PowerNV machines and extend the
>>> XIVE models with the new XiveFabric and XivePresenter interfaces to
>>> provide support for XIVE escalations and interrupt resend. This
>>> mechanism is used by XIVE to notify the hypervisor that a vCPU is not
>>> dispatched on a HW thread. Tested on a QEMU PowerNV machine and a
>>> simple QEMU pseries guest doing network on a local bridge.
>>>
>>> The XIVE interrupt controller offers a way to increase the XIVE
>>> resources per chip by configuring multiple XIVE blocks on a chip. This
>>> is not currently supported by the model. However, some configurations,
>>> such as OPAL/skiboot, use one block-per-chip configuration with some
>>> optimizations. One of them is to override the hardwired chip ID by the
>>> block id in the PowerBUS operations and for CAM line compares. This
>>> patchset improves the support for this setup. Tested with 4 chips.
>>
>> David,
>>
>> Do you want me to resend this patchset ? or you just didn't have time
>> to look at it ?  
> 
> Mostly, I just haven't had time.  I'm also finding the patches pretty
> difficult to read and review.  I don't think that's an indication
> they're bad, just that what they're doing is necessarily complex, but
> it's still made it hard to tackle them.

I will try to split the initial patches on the presenter a little more.


>> Patch 16 has changed a little since. The get_block_id() handler has 
>> moved to the XiveRouterClass.
> 
> You, might as well repost, so I'm looking at the latest stuff.  I
> can't promise I'll be able to look at the new set terribly soon
> though.

ok.

thanks,

C.