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.campb...@citrix.com> 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.ca...@citrix.com> > 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@lists.xen.org http://lists.xen.org/xen-devel