From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: [early RFC] ARM PCI Passthrough design document Date: Wed, 8 Mar 2017 11:55:28 -0800 (PST) Message-ID: References: <5cf9128e-e845-2a89-f7c7-ac8616941ab9@linaro.org> <56a2cd48-f7cf-25ca-2bfe-cabf02d34df3@linaro.org> <8ca91073-09e7-57ca-9063-b47e0aced39d@linaro.org> <20170201105525.jm5uf6wpbzzeid4d@dhcp-3-221.uk.xensource.com> <6b279b84-aa0f-7557-390e-dc66db90036f@linaro.org> <782775bb-cb63-776f-5e5c-0c96cd523972@linaro.org> <20170308191209.GG8530@char.us.oracle.com> Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-959480918-1489002929=:8160" Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1clhgN-0008AZ-4R for xen-devel@lists.xenproject.org; Wed, 08 Mar 2017 19:55:35 +0000 In-Reply-To: <20170308191209.GG8530@char.us.oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Konrad Rzeszutek Wilk Cc: "Edgar Iglesias (edgar.iglesias@xilinx.com)" , Stefano Stabellini , Wei Chen , Steve Capper , Andrew Cooper , Jiandi An , Julien Grall , alistair.francis@xilinx.com, Punit Agrawal , Campbell Sean , xen-devel , "manish.jaggi@caviumnetworks.com" , Shanker Donthineni , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= List-Id: xen-devel@lists.xenproject.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-959480918-1489002929=:8160 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Wed, 8 Mar 2017, Konrad Rzeszutek Wilk wrote: > On Wed, Mar 08, 2017 at 07:06:23PM +0000, Julien Grall wrote: > > Hi, > > > > On 02/02/17 23:06, Stefano Stabellini wrote: > > > On Thu, 2 Feb 2017, Julien Grall wrote: > > > > On 01/02/17 10:55, Roger Pau Monné wrote: > > > > > On Wed, Jan 25, 2017 at 06:53:20PM +0000, Julien Grall wrote: > > > > > > On 24/01/17 20:07, Stefano Stabellini wrote: > > > > > > > On Tue, 24 Jan 2017, Julien Grall wrote: > > > > For DT, I would have a fallback on mapping the root complex to DOM0 if we > > > > don't support it. So DOM0 could still use PCI. > > > > > > > > For ACPI, I am expecting all the platform ECAM compliant or require few > > > > quirks. So I would mandate the support of the root complex in Xen in order to > > > > get PCI supported. > > > > > > Sound good. Ack. > > > > I am currently rewriting the design document to take into account all the > > comments and follow the path to have the host bridge in Xen and DOM0 will > > get an emulated one. > > > > I began to look at scanning and configuring PCI devices in Xen. Looking at > > the PCI firmware specification, the firmware is not required to configure > > the BAR register other than for boot and console devices. This means an > > Operating System (or the hypervisor in our case) may have to configure some > > devices. > > > > In order to configure the BAR register, Xen would need to know where are the > > PCI resources. On ACPI they can be found in ASL, however Xen is not able to > > parse it. In the case of Device Tree with can retrieve the PCI resources > > using the property "ranges". > > > > I can see a couple of solutions: > > 1# Rely on DOM0 to do the PCI configuration. This means that DOM0 should > > see all the PCI devices and therefore will not be possible to hide from DOM0 > > if we know at boot a device will be used by a guest (i.e something similar > > to pciback.hide but directly handled in Xen). > > .. this as for SR-IOV devices you need the drivers to kick the hardware > to generate the new bus addresses. And those (along with the BAR regions) are > not visible in ACPI (they are constructued dynamically). Yes indeed. In truth, SR-IOV is a much bigger problem than the BARs. In reality, the BARs are always setup by the firmware (all cases I have seen), but SR-IOV definitely need the Linux driver to poke the device. > > 2# Add an ASL interpreter in Xen. Roger mentioned that openbsd as a DSDT > > parser in 4000 lines (see [1]). > > > > Any opinions? --8323329-959480918-1489002929=:8160 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --8323329-959480918-1489002929=:8160--