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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

>> Also you appear to be losing all RAM in [fc009000, fee00000).
> 
> This is not populated. Note how:
> 
> 0x000001fe000400 - 0x000001fb200400 == 0x000000fee00000 - 0x000000fc000000
> 
> The memory is shifted towards the end.

Oh, I see - I didn't pay attention to the upper bound of that last entry,
I'm sorry.

Jan



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