Re: [early RFC] ARM PCI Passthrough design document

From: Stefano Stabellini <sstabellini@kernel.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: "Edgar Iglesias (edgar.iglesias@xilinx.com)"
	<edgar.iglesias@xilinx.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Wei Chen" <Wei.Chen@arm.com>,
	"Steve Capper" <Steve.Capper@arm.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Jiandi An" <anjiandi@codeaurora.org>,
	"Julien Grall" <julien.grall@linaro.org>,
	alistair.francis@xilinx.com,
	"Punit Agrawal" <punit.agrawal@arm.com>,
	"Campbell Sean" <scampbel@codeaurora.org>,
	xen-devel <xen-devel@lists.xenproject.org>,
	"manish.jaggi@caviumnetworks.com"
	<manish.jaggi@caviumnetworks.com>,
	"Shanker Donthineni" <shankerd@codeaurora.org>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [early RFC] ARM PCI Passthrough design document
Date: Wed, 8 Mar 2017 11:55:28 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.2.10.1703081153130.8160@sstabellini-ThinkPad-X260> (raw)
In-Reply-To: <20170308191209.GG8530@char.us.oracle.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2516 bytes --]

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?

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel