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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Tue, Jan 24, 2017 at 12:07:16PM -0800, Stefano Stabellini wrote:
> On Tue, 24 Jan 2017, Julien Grall wrote:
> > > > ## Discovering and register hostbridge
> > > > 
> > > > Both ACPI and Device Tree do not provide enough information to fully
> > > > instantiate an host bridge driver. In the case of ACPI, some data may 
> > > > come
> > > > from ASL,
> > > 
> > > The data available from ASL is just to initialize quirks and non-ECAM
> > > controllers, right? Given that SBSA mandates ECAM, and we assume that
> > > ACPI is mostly (if not only) for servers, then I think it is safe to say
> > > that in the case of ACPI we should have all the info to fully
> > > instantiate an host bridge driver.
> > 
> > From the spec, the MCFG will only describe host bridge available at boot 
> > (see
> > 4.2 in "PCI firmware specification, rev 3.2"). All the other host bridges 
> > will
> > be described in ASL.
> > 
> > So we need DOM0 to feed Xen about the latter host bridges.
> 
> Unfortunately PCI specs are only accessible by PCI SIG members
> organizations. In other words, I cannot read the doc.

I know, I had to register at PCI-SIG in order to access the specs, which makes
no sense to me.

> Could you please explain what kind of host bridges are not expected to
> be available at boot? Do you know of any examples?

It's possible for host bridges to be hot-plugged during runtime according to
the spec. Those bridges will not appear in the MCFG, but will have objects in
the ACPI namespace with _CBA methods that will return this information.

I have never seen anything like this on real systems, and to put an example
FreeBSD AFAICT will only detect host bridges present in the MCFG (and I've
never seen anyone complaining about it).

Roger.

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