On Thu, 2017-12-14 at 16:24 +0100, Cédric Le Goater wrote: > 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.
In HW it's an MMIO store between the two units (from the source to the IVRE notification port). I wonder in the long run if we should model that the same way... > 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.
