Re: [Qemu-devel] [PATCH v2 03/19] spapr: introduce the XIVE interrupt sources

[Cédric Le Goater]

> diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h
> index 5b1f78e06a1e..ecc15d889b74 100644
> --- a/include/hw/ppc/spapr_xive.h
> +++ b/include/hw/ppc/spapr_xive.h
> @@ -24,8 +24,17 @@ struct sPAPRXive {
>      /* Properties */
>      uint32_t     nr_irqs;
>  
> +    /* IRQ */
> +    qemu_irq     *qirqs;
> +
>      /* XIVE internal tables */
>      XiveIVE      *ivt;
> +    uint8_t      *sbe;
> +    uint32_t     sbe_size;
> +
> +    /* ESB memory region */
> +    hwaddr       esb_base;
> +    MemoryRegion esb_iomem;
>  };
>  
>  bool spapr_xive_irq_enable(sPAPRXive *xive, uint32_t lisn);
> 

The addition of the XIVE source fields directly under the sPAPRXive 
object is really a design choice. But I am starting to think that 
having multiple XIVE source objects would be a good idea.

Roughly speaking, a XIVE source is a bunch of PQ bits plus a MMIO 
region to manipulate them and, in the QEMU model, a set of associated 
qemu_irqs to do the same from the handlers. 

In real HW, the PSI host bridge controller on the P9 for instance, 
a register holds all the P bits of the IRQs (no Q bits because the 
IRQs are only LSIs) and there is a specific MMIO region for them. 
PSIHB also has a register to store the assertion level of each IRQ.   
So this is quite similar to what we are adding above and in the
next patch for the LSI support. 

The source triggering only depends on the PQ bits (plus the LSI 
level) and the result is a simple forward of the event notification 
to the central XIVE engine : the IVRE, doing the routing. The IVRE
is really our sPAPRXive object. 

The API between the source and the IVRE is extremely simple :

  static void spapr_xive_irq(sPAPRXive *xive, int lisn)

The IVRE then scans its IVT, finds the EQ, and moves on to the 
presenter.

So, we can keep the IVRE engine (sPAPRXive) attached directly to 
the machine like we have today, this is good, and introduce multiple 
XIVE source objects. The sPAPR machine would have : 

 - one for the IPIs [ 0 - nr_servers ]
 - one generic for the devices [ 4096 -  ]
 - one for each phb ? 

The source address in the overall ESB MMIO region would be calculated 
from the offset of the source IRQ numbers in the IRQ number space. 
The offset could very well be hardcoded for each device. I don't see 
any XICS compatibility problems as we are sharing correctly the IRQ 
number space already.


I am starting this discussion because the support for XIVE in the 
QEMU PowerNV machine will need multiple sources, just like for 
POWER8. PnvXive will be a bit different because the IVRE tables 
(IVT and EQDT) are in the virtual machine memory. Most of the settings 
are done in the VM. The QEMU PowerNV machine will still have to 
implement the triggering and the routing logic using the guest tables. 


Regards,

C.