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 13:22:03 +0000 Message-ID: <1425043323.14641.193.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> <1425033490.14641.160.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1425033490.14641.160.camel@citrix.com> 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 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 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.