Re: [Xen-devel] RFC: [PATCH 1/3] Enhance platform support for PCI

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 27 Feb 2015, Ian Campbell wrote:
> On Fri, 2015-02-27 at 16:35 +0000, Jan Beulich wrote:
> > >>> On 27.02.15 at 16:24, <ian.campbell@xxxxxxxxxx> wrote:
> > > On Fri, 2015-02-27 at 14:54 +0000, Stefano Stabellini wrote:
> > >> MMCFG is a Linux config option, not to be confused with
> > >> PHYSDEVOP_pci_mmcfg_reserved that is a Xen hypercall interface.  I don't
> > >> think that the way Linux (or FreeBSD) call PHYSDEVOP_pci_mmcfg_reserved
> > >> is relevant.
> > > 
> > > My (possibly flawed) understanding was that pci_mmcfg_reserved was
> > > intended to propagate the result of dom0 parsing some firmware table or
> > > other to the hypevisor.
> > 
> > That's not flawed at all.
> 
> I think that's a first in this thread ;-)
> 
> > > In Linux dom0 we call it walking pci_mmcfg_list, which looking at
> > > arch/x86/pci/mmconfig-shared.c pci_parse_mcfg is populated by walking
> > > over a "struct acpi_table_mcfg" (there also appears to be a bunch of
> > > processor family derived entries, which I guess are "quirks" of some
> > > sort).
> > 
> > Right - this parses ACPI tables (plus applies some knowledge about
> > certain specific systems/chipsets/CPUs) and verifies that the space
> > needed for the MMCFG region is properly reserved either in E820 or
> > in the ACPI specified resources (only if so Linux decides to use
> > MMCFG and consequently also tells Xen that it may use it).
> 
> Thanks.
> 
> So I think what I wrote in <1424948710.14641.25.camel@xxxxxxxxxx>
> applies as is to Device Tree based ARM devices, including the need for
> the PHYSDEVOP_pci_host_bridge_add call.

Although I understand now that PHYSDEVOP_pci_mmcfg_reserved was
intendend for passing down firmware information to Xen, as the
information that we need is exactly the same, I think it would be
acceptable to use the same hypercall on ARM too.

I am not hard set on this and the new hypercall is also a viable option.
However If we do introduce a new hypercall as Ian suggested, do we need
to take into account the possibility that an host bridge might have
multiple cfg memory ranges?


> On ACPI based devices we will have the MCFG table, and things follow
> much as for x86:
> 
>       * Xen should parse MCFG to discover the PCI host-bridges
>       * Dom0 should do likewise and call PHYSDEVOP_pci_mmcfg_reserved in
>         the same way as Xen/x86 does.
> 
> The SBSA, an ARM standard for "servers", mandates various things which
> we can rely on here because ACPI on ARM requires an SBSA compliant
> system. So things like odd quirks in PCI controllers or magic setup are
> spec'd out of our zone of caring (into the firmware I suppose), hence
> there is nothing like the DT_DEVICE_START stuff to register specific
> drivers etc.
> 
> The PHYSDEVOP_pci_host_bridge_add call is not AFAICT needed on ACPI ARM
> systems (any more than it is on x86). We can decide whether to omit it
> from dom0 or ignore it from Xen later on.
> 
> (Manish, this is FYI, I don't expect you to implement ACPI support!)

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