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

[Juergen Gross <jgross@xxxxxxxx>]

On 20/04/18 17:09, Andrew Cooper wrote:
> 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.

Hmm, I'd rather put the ACPI tables between 3G and 4G. They are not
accessed that often. The guest has then no need to use smaller pages
for direct RAM mappings due to ACPI RO-mappings.


Juergen

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