Re: [Xen-devel] HVMlite ABI specification DRAFT B + implementation outline

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 09.02.16 at 12:58, <roger.pau@xxxxxxxxxx> wrote:
> El 9/2/16 a les 11:56, Andrew Cooper ha escrit:
>> On 08/02/16 19:03, Roger Pau Monnà wrote:
>>>  * PCI Express MMCFG: if Xen is able to identify any of these regions at 
>>> boot
>>>    time they will also be made available to the guest at the same position
>>>    in it's physical memory map. It is possible that Xen will trap accesses 
>>> to
>>>    those regions, but a guest should be able to use the native configuration
>>>    mechanism in order to interact with this configuration space. If the
>>>    hardware domain reports the presence of any of those regions using the
>>>    PHYSDEVOP_pci_mmcfg_reserved hypercall Xen will also all guest access to
>>>    them.
>>>
>>>  * PCI BARs: it's not possible for Xen to know the position of the BARs of
>>>    the PCI devices without hardware domain interaction.
>> 
>> Xen requires no dom0 interaction to find all information like this for
>> devices in segment 0 (i.e. all current hardware).  Segments other than 0
>> may have their MMCONF regions expressed in AML only.
> 
> Thanks for the comments, please bear with me. I think we are mixing two
> things here, one is the MMCFG areas, and the other one are the BARs of
> each PCI device.
> 
> AFAIK MMCFG areas are described in the 'MCFG' ACPI table, which is
> static and Xen should be able to parse on it's own. Then I'm not sure
> why PHYSDEVOP_pci_mmcfg_reserved is needed at all.

Because there are safety nets: Xen and Linux consult the memory
map to determine whether actually using what the firmware say is
an MMCFG area is actually safe. Linux in addition checks ACPI
tables, and this is what Xen can't do (as it require an AML
interpreter), hence the hypercall to inform the hypervisor.

> Then for BARs you need to know the specific PCI devices, which are
> enumerated in the DSDT or similar ACPI tables, which are not static, and
> thus cannot be parsed by Xen. We could do a brute force scan of the
> whole PCI bus using the config registers, but that seems hacky. And as
> Boris said we need to keep the usage of PHYSDEVOP_pci_device_add in
> order to notify Xen of the PXM information.

We can only be sure to have access to segment 0 at boot time.
Other segments may be accessible via MMCFG only, and whether
we can safely use the respective MMCFG we won't know - see
above - early enough. That's also the reason why today we do a
brute force scan only on segment 0.

Jan

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