From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: RFC: [PATCH 1/3] Enhance platform support for PCI Date: Fri, 27 Feb 2015 10:38:10 +0000 Message-ID: <1425033490.14641.160.camel@citrix.com> References: <54E71BDE.5020106@caviumnetworks.com> <54E7229C.7000301@linaro.org> <54E72452.3090801@caviumnetworks.com> <54E72688.9010005@linaro.org> <54E729F1.6000804@caviumnetworks.com> <54E73010.2050902@caviumnetworks.com> <1424439941.30924.243.camel@citrix.com> <54E74135.4040302@caviumnetworks.com> <1424443185.30924.268.camel@citrix.com> <54EB0813.20909@caviumnetworks.com> <54EB0B7D.6060909@linaro.org> <54EB1401.2050609@caviumnetworks.com> <54EB440C.9010806@linaro.org> <54EB5F86.40607@caviumnetworks.com> <54EB9E13.7060802@linaro.org> <54EBC47E.4040801@caviumnetworks.com> <54EC8007.1090405@linaro.org> <54ED345C.8020902@caviumnetworks.com> <1424859603.20243.71.camel@citrix.com> <54EF38EE.3060309@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Pranavkumar Sawargaonkar Cc: prasun.kapoor@cavium.com, Vijay Kilari , Manish Jaggi , "Kumar, Vijaya" , Julien Grall , "xen-devel@lists.xen.org" , "Stefano Stabellini (Stefano.Stabellini@citrix.com)" , Jan Beulich List-Id: xen-devel@lists.xenproject.org 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 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.