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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.02.15 at 16:01, <ian.campbell@xxxxxxxxxx> wrote:
> On Fri, 2015-02-20 at 14:39 +0000, Jan Beulich wrote:
>>  plus the MMCFG reporting one (PHYSDEVOP_pci_mmcfg_reserved).
> 
> This looks promising, but rather under-documented.
> 
>         #define PHYSDEVOP_pci_mmcfg_reserved    24
>         struct physdev_pci_mmcfg_reserved {
>             uint64_t address;
>             uint16_t segment;
>             uint8_t start_bus;
>             uint8_t end_bus;
>             uint32_t flags;
>         };
>         
> I suppose the first 4 fields correspond to entries in the MMCFG table?

Yes.

> Which x86 Xen can parse and so can dom0, so dom0 can then make this
> hypercall, passing (address,segment,start_bus,end_bus) to set the flags?

No, the flags are IN too - since Xen can parse the table itself, there
wouldn't be any need for the hypercall if there weren't many systems
which don't reserve the MMCFG address range(s) in E820 and/or ACPI
resources. Xen can check E820, but obtaining ACPI resource info
requires AML parsing.

> What is address the address of? The CFG space I think?

Yes, the base address of the MMCFG range (maybe suitably offset
by the bus number).

> On ARM with DT I think we only get given address, and something has to
> make up segment, start/end_bus I'm not sure where we would get them
> from.
> 
> So although I think we could perhaps bend this interface to ARMs needs
> it would have rather different semantics to x86, i.e. instead of the
> "key" being (address,segment,start_bus,end_bus) and the "value" being
> flags it would be something like "key" = (address) and "value" =
> (segment,start_bus,end_bus,flags).
> 
> I don't think reusing like that would be wise.

Yes, sufficiently different semantics would call for a new interface.

>>  Without ACPI, how do you
>> know on ARM how to access config space for a particular
>> segment?
> 
> That's the issue we are trying to resolve, with device tree there is no
> explicit segment ID, so we have an essentially unindexed set of PCI
> buses in both Xen and dom0.

How that? What if two bus numbers are equal? There ought to be
some kind of topology information. Or if all buses are distinct, then
you don't need a segment number.

Jan


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