[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Benjamin Herrenschmidt
Subject: Re: [Qemu-ppc] [PATCH v2 03/19] spapr: introduce the XIVE interrupt sources
Date: Mon, 18 Dec 2017 11:59:41 +1100

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. 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]