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

[Manish Jaggi <mjaggi@caviumnetworks.com>]

On Friday 27 February 2015 10:20 PM, Ian Campbell wrote:
> On Fri, 2015-02-27 at 16:35 +0000, Jan Beulich wrote:
>>>>> On 27.02.15 at 16:24, <ian.campbell@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.camel@citrix.com>
> 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!)

In drivers/xen/pci.c on notification BUS_NOTIFY_ADD_DEVICE dom0 issues a 
hypercall to inform xen that a new pci device has been added.
If we were to inform xen about a new pci bus that is added there are  2 ways
a) Issue the hypercall from drivers/pci/probe.c
b) When a new device is found (BUS_NOTIFY_ADD_DEVICE) issue 
PHYSDEVOP_pci_device_add hypercall to xen, if xen does not finds that 
segment number (s_bdf), it will return an error
SEG_NO_NOT_FOUND. After that the linux xen code could issue the 
PHYSDEVOP_pci_host_bridge_add hypercall.

I think (b) can be done with minimal code changes. What do you think ?

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