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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 09.02.16 at 14:00, <roger.pau@xxxxxxxxxx> wrote:
> El 9/2/16 a les 13:10, Jan Beulich ha escrit:
>>>>> 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.
> 
> Hm, I guess I'm overlooking something, but I think Xen checks the ACPI
> tables, see xen/arch/x86/x86_64/mmconfig-shared.c:400:
> 
>     if (pci_mmcfg_check_hostbridge()) {
>         unsigned int i;
> 
>         pci_mmcfg_arch_init();
>         for (i = 0; i < pci_mmcfg_config_num; ++i)
>             if (pci_mmcfg_arch_enable(i))
>                 valid = 0;
>     } else {
>         acpi_table_parse(ACPI_SIG_MCFG, acpi_parse_mcfg);
>         pci_mmcfg_arch_init();
>         valid = pci_mmcfg_reject_broken();
>     }
> 
> Which AFAICT suggests that Xen is indeed able to parse the 'MCFG' table,
> which contains the list of MMCFG regions on the system. Is there any
> other ACPI table where this information is reported that I'm missing?

You didn't read my reply carefully enough: I didn't say Xen can't
parse these tables. What I said is that Xen isn't by itself in the
position to do sanity checks that have proven necessary. Hence ...

> This would suggest then that the hypercall is no longer needed.

... it's needed - see Linux'es is_mmconf_reserved() which checks
both E820 and data read from DSDT (and maybe SSDT). Also
please don't forget about the hotplug case, where _CBA methods
need evaluation in order to obtain address information.

>>> 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.
> 
> Andrew suggested that all current hardware only uses segment 0, so it
> seems like covering segment 0 is all that's needed for now. Are OSes
> already capable of dealing with segments different than 0 that only
> support MMCFG accesses?

Of course - Linux for example. I've actually seen Linux (and Xen) run
on a system with multiple segments.

> And in which case, if a segment != 0 appears, and it only supports MMCFG
> accesses, the MCFG table should contain an entry for this area, which
> should allow us to properly scan it.

See above.

Jan

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