Re: [Xen-devel] [PATCH for-4.11] libxl: fix memory map reported to PVH guests

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 20/04/18 15:31, Roger Pau Monné wrote:
> On Fri, Apr 20, 2018 at 08:25:41AM -0600, Jan Beulich wrote:
>>>>> On 20.04.18 at 16:15, <roger.pau@xxxxxxxxxx> wrote:
>>> On Fri, Apr 20, 2018 at 08:01:35AM -0600, Jan Beulich wrote:
>>>>>>> On 20.04.18 at 15:52, <roger.pau@xxxxxxxxxx> wrote:
>>>>> PVH guests with 4GB of RAM or more get a memory map like the
>>>>> following:
>>>>>
>>>>> 0x00000000000000 - 0x000000fee00000 RAM
>>>>> 0x000000fee00000 - 0x00000100000000 RESERVED
>>>>> 0x000000fc009000 - 0x000000fc009040 ACPI
>>>>> 0x000000fc000000 - 0x000000fc001000 ACPI
>>>>> 0x000000fc001000 - 0x000000fc009000 ACPI
>>>>> 0x00000100000000 - 0x000001fb200400 RAM
>>>>>
>>>>> This is wrong because ACPI regions are also reported as RAM regions.
>>>>> The cause of this issue is not setting a big enough MMIO hole, current
>>>>> libxl code only takes into account the address of the local APIC page
>>>>> and the reserved pages in order to set the size of the MMIO hole, when
>>>>> it should also take into account the location of the ACPI tables.
>>>>>
>>>>> After the fix the layout reported for the same guest is:
>>>>>
>>>>> 0x00000000000000 - 0x000000fc000000 RAM
>>>>> 0x000000fc000000 - 0x00000100000000 RESERVED
>>>>> 0x000000fc009000 - 0x000000fc009040 ACPI
>>>>> 0x000000fc000000 - 0x000000fc001000 ACPI
>>>>> 0x000000fc001000 - 0x000000fc009000 ACPI
>>>>> 0x00000100000000 - 0x000001fe000400 RAM
>>>> But this is still wrong - no two regions may overlap, regardless of type.
>>> It's going to be more complicated to fix that. I can give it a try,
>>> but I think this is strictly better than what we do now.
>>>
>>> Maybe instead of marking the whole MMIO hole as reserved we should
>>> only mark as reserved the lapic page and the special pages? That
>>> should avoid any overlaps.
>> Well, if nothing else is in that range (or can be placed there dynamically at
>> runtime) I don't see why all of it is reserved. Marking a range reserved
>> prevents, for example, PCI device BARs to be put there by the OS. The
>> way it looks there's no MMIO window left available at all below 4Gb ...
> Right, this will change when PVH gets devices with BARs, then it's
> going to need a proper MMIO hole below 4GB

Whomever wants to make PVH guests work properly fast:

The only way this work while retaining 1G host superpages is to
unilaterally split at the 3G mark and continue from the 4G boundary. 
The ACPI tables and other ram-based tables can grow down from 3G, and
there is plenty of room for the LAPIC to work, a sensibly sized MMIO
hole, and gfn room to put mappings into without shattering superpages.

Then we've got to see about how to not use MTRRs...

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel