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

[Manish Jaggi <mjaggi@xxxxxxxxxxxxxxxxxx>]

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@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.
>
> 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@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

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