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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Fri, 2015-02-27 at 10:38 +0000, Ian Campbell wrote:
> 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@xxxxxxxxxx> 
> > 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.

Or perhaps I'm confusing interrupt translation here with the SMMU
translation of the device's DMA writes to the MSI doorbell address?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel