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

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2851 bytes --]

On Tue, Dec 19, 2017 at 07:37:31AM +0100, Cédric Le Goater wrote:
> On 12/18/2017 01:59 AM, Benjamin Herrenschmidt wrote:
> > 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...
> 
> It's a problem for PowerNV. IVSEs should all have an 'IVT offset' 
> register and a 'notify trigger port address' address register for 
> this purpose. Real HW performs a 4bytes store of the IRQ number 
> to forward the notification to the IVRE. It even makes the model 
> a little simpler because we don't have to look for the appropriate 
> PnvXive object to handle the routing.  
> 
> For sPAPR, we don't have such MMIOs but still, we could trigger 
> directly the sPAPRXive object without using the qemu_irq objects
> which stand in the middle. XIVE IPIs don't use them at all and
> only use MMIOs.

Yeah, I think we're going to want a model more explicitly close to
what the hardware does.  It's tempting to shortcut it for PAPR, but a)
it'll probably cause us less trouble when we need to implement powernv
and b) I think it's less likely to break as we fill out the various
details we need.

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]