Re: HVMlite ABI specification DRAFT B + implementation outline

["Roger Pau Monné" <roger.pau@citrix.com>]

El 9/2/16 a les 14:41, Jan Beulich ha escrit:
>>>> On 09.02.16 at 14:00, <roger.pau@citrix.com> wrote:
>> 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 ...

Sorry, Ack, AFAICT FreeBSD is much more naive in this aspect and blindly
trusts what the ACPI MCFG table contains (or at least it seems to me
that way).

I'm not going to argue since you say that this has proven necessary, but
are this kind of broken systems still around? PVH/HVMlite requires
recent hardware in order to run, so maybe things have improved since
this was implemented.

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

Right, _CBA methods report the ECAM space, and are the only way to get
this information in the hotplug case I guess.

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

Right, I wasn't specially trilled to remove these two PHYSDEV hypercalls
anyway, they are not very intrusive IMHO. We still need to figure out
how to do MMIO mapping of BARs however. We can continue the discussion
about MMIO mappings on your other reply to the ABI
<56B9F69002000078000D012B@prv-mh.provo.novell.com>.

Roger.