[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] RFC: [PATCH 1/3] Enhance platform support for PCI
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. 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. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |