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

[Ian Campbell <ian.campbell@citrix.com>]

On Fri, 2015-02-27 at 14:54 +0000, Stefano Stabellini wrote:
> > My understanding from discussion with Jan was that this is not what this
> > hypercall does, or at least that this would be an abuse of the existing
> > interface. See: <54E75D8702000078000621DD@mail.emea.novell.com>
>  
> If all the fields in struct physdev_pci_mmcfg_reserved, including flags,
> are IN parameters, like Jan wrote in his email, how is it an abuse of the
> interface?

AIUI they are IN parameters in the sense that they provide the "Key",
while flags is the "Value" in this hypercall.

> It seems to me that we would be using it exactly as intended.
> 
> As the author of this interface, of course I'll trust Jan's judgement on
> this.
> 
> 
> > Anyway, what happens for when there is no MMCFG table to drive dom0's
> > calls to pci_mmcfg_reserved?
> 
> 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.

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

> > Or a given host-bridge doesn't have special
> > flags and so isn't mentioned there.
> 
> flags could be zero?

What I meant was: isn't mentioned in the firmware table and so there is
no corresponding call at all.

Ian.

> 
> 
> > I think a dedicated hypercall is better.
>