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

[Cédric Le Goater]

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.    

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