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

[Manish Jaggi <mjaggi@caviumnetworks.com>]

On Monday 02 March 2015 05:18 PM, Ian Campbell wrote:
> On Fri, 2015-02-27 at 17:15 +0000, Stefano Stabellini wrote:
>> 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.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.
>> 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 strongly disagree, they have very different semantics and overloading
> the existing interface would be both wrong and confusing.
>
> It'll also make things harder in the ACPI case where we want to use the
> existing hypercall for its original purpose (to propagate MCFG
> information to Xen).
>
>> 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?
> I don't believe so, a host bridge has a 1:1 relationship with CFG space.
>
> Ian.
>
I agree with this flow. It fits into what we have implemented at our end.
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel