Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

[Julien Grall <julien.grall@xxxxxxxxxx>]

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).
	2# Add an ASL interpreter in Xen. Roger mentioned that openbsd as a 
DSDT parser in 4000 lines (see [1]).
Any opinions?

Cheers,

[1] https://github.com/openbsd/src/blob/master/sys/dev/acpi/dsdt.c

--
Julien Grall

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