From mboxrd@z Thu Jan 1 00:00:00 1970 From: Manish Subject: Re: [PATCH for-4.6 0/5] xen: arm: Parse PCI DT nodes' ranges and interrupt-map Date: Thu, 19 Feb 2015 10:46:17 +0530 Message-ID: <54E571A1.8020907@caviumnetworks.com> References: <1414144694.15687.31.camel@citrix.com> <54E168D6.6000502@amd.com> <54E1C2AA.3070504@linaro.org> <54E2AFCC.3090302@amd.com> <54E34592.2020803@linaro.org> <54E3472D.6030103@citrix.com> <54E3C21A.6080909@amd.com> <54E3DD71.6070001@amd.com> <54E422FE.4080803@amd.com> <54E48A0F.80900@linaro.org> <54E4F24E.2020602@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54E4F24E.2020602@amd.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: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 19/02/15 1:43 am, Suravee Suthikulanit wrote: > On 2/18/2015 6:48 AM, Julien Grall wrote: >> Hi Suravee, >> >> On 18/02/2015 05:28, Suravee Suthikulanit wrote: >>> >>> Actually, that seems to be more related to the PCI pass-through >>> devices. >>> Isn't the Cavium guys already done that work to support their PCI >>> device >>> pass-through? >> >> They were working on it, but so far there is no patch series on the ML. >> It would be nice to come with a common solution (i.e between GICv2m and >> GICv3 ITS) for MSI. > > Agree, although for supporting Dom0 MSI, I don't see anything that > could be shared since this would totally be two separate > drivers/interfaces. > >> >>> Anyways, at this point, I am able to generated Dom0 device tree with >>> correct v2m node, and I can see Dom0 gicv2m driver probing and >>> initializing correctly as it would on bare-metal. >>> >>> # Snippet from /sys/firmware/fdt showing dom0 GIC node >>> interrupt-controller { >>> compatible = "arm,gic-400", "arm,cortex-a15-gic"; >>> #interrupt-cells = <0x3>; >>> interrupt-controller; >>> reg = <0x0 0xe1110000 0x0 0x1000 0x0 0xe112f000 0x0 0x2000>; >>> phandle = <0x1>; >>> #address-cells = <0x2>; >>> #size-cells = <0x2>; >>> ranges = <0x0 0x0 0x0 0xe1100000 0x0 0x100000>; >>> >>> v2m { >>> compatible = "arm,gic-v2m-frame"; >>> msi-controller; >>> arm,msi-base-spi = <0x40>; >>> arm,msi-num-spis = <0x100>; >>> phandle = <0x5>; >>> reg = <0x0 0x80000 0x0 0x1000>; >>> }; >>> }; >>> >>> linux:~ # dmesg | grep v2m >>> [ 0.000000] GICv2m: Overriding V2M MSI_TYPER (base:64, num:256) >>> [ 0.000000] GICv2m: Node v2m: range[0xe1180000:0xe1180fff], >>> SPI[64:320] >>> >>> So, during setting up v2m in hypervisor, I also call >>> route_irq_to_guest() for the all SPIs used for MSI (i.e. 64-320 on >>> Seattle), which will force the MSIs to Dom0. However, we would need to >>> figure out how to detach and re-route certain interrupts to a specific >>> DomU in case of passing through PCI devices in the future. >> >> Who decide to assign the MSI n to the SPI x? DOM0 or Xen? > > For v2m, each MSI is tied to a specific SPI. The range of SPIs is > specified in the GIC V2M_MSI_TYPER register. In Xen, we need to make > sure that these are routed to Dom0 initially since Dom0 GICv2m driver > is the one handling all MSI assignments. > >> Wouldn't it be possible to route the SPI dynamically when the domain >> decide to use the MSI n? We would need to implement PHYSDEVOP_map_pirq >> for MSI. > > Enabling MSI is done by each end-point PCI device drivers in the > guest. In Linux, this would mean that when the driver tries to > allocate an MSI interrupt, it would need to communicate back to Xen > (possibly via hypercall as you pointed out) to get the next available > SPI. It is not necessary for now. I am planning to revisit this when > we try to implement pass-through support. Lemme know if you think this > should be handled differently. > For cavium we are doing it differently. In the frontend bus we have added its. I am planning to send RFC patches soon. > Cheers, > > Suravee > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel