[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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).


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.

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.