> 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.
