Re: RFC: [PATCH 1/3] Enhance platform support for PCI

[Ian Campbell <ian.campbell@citrix.com>]

On Fri, 2015-02-27 at 15:41 +0530, Pranavkumar Sawargaonkar wrote:
> Hi Julien,
> 
> On Thu, Feb 26, 2015 at 8:47 PM, Julien Grall <julien.grall@linaro.org> wrote:
> > On 26/02/15 14:46, Pranavkumar Sawargaonkar wrote:
> >> Hi
> >
> > Hi Pranavkumar,
> >
> >> Also if we just show only one vITS (or only one Virtual v2m frame)
> >> instead of two vITS
> >> then actual hardware interrupt number and virtual interrupt number
> >> which guest will see will become different
> >> This will hamper direct irq routing to guest.
> >
> > The IRQ injection should not consider a 1:1 mapping between pIRQ and vIRQ.
> 
> Yes, but in case of GICv2m( I am not sure about ITS) in register
> MSI_SETSPI_NS device has to write the interrupt ID (which is pirq) to
> generate an interrupt.
> If you write virq which is different that pirq (associated with the
> actual GICv2m frame ) then it will not trigger any interrupt.
> 
> Now there is case which I am not sure how it can be solvable with one
> vITS/vGICv2m  -
> 
> . Suppose we have two GICv2m frames and say oneis  having an address
> 0x1000 for MSI_SETSPI_NS register and other 0x2000 for it's
> MSI_SETSPI_NS register
> . Assume first frame has SPI's (physical) 0x64 - 0x72 associated and
> second has 0x80-0x88 associated.
> . Now there are two PCIe hosts, first using first GICv2m frame as a
> MSI parent and another using second frame.
> . Device on first host uses MSI_SETSPI_NS (0x1000) address along with
> a data (i.e. intr number say 0x64) and device on second host uses
> 0x2000 and data 0x80
> 
> Now if we show one vGICv2m frame in guest for both the devices then
> what address I will program in each device's config space for MSI and
> also what will the data value.
> Secondly device's write for these addresses will be transparent to cpu
> so how can we trap them while device wants to trigger any interrupt ?
>
> Please correct me if I misunderstood anything.

Is what you are suggesting a v2m specific issue?

I thought the whole point of the ITS stuff in GICv3 was that one could
program such virt-phys mappings into the hardware ITS and it would do
the translation (the T in ITS) such that the host got the pIRQ it was
expecting when the guest wrote the virtualised vIRQ information to the
device.

Caveat: If I've read the ITS bits of that doc at any point it was long
ago and I've forgotten everything I knew about it... And I've never read
anything about v2m at all ;-)

Ian.