Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

[Juergen Gross <jgross@xxxxxxxx>]

On 20/11/17 17:14, Jan Beulich wrote:
>>>> On 20.11.17 at 16:24, <jgross@xxxxxxxx> wrote:
>> On 20/11/17 15:20, Jan Beulich wrote:
>>>>>> On 20.11.17 at 15:14, <jgross@xxxxxxxx> wrote:
>>>> On 20/11/17 14:56, Boris Ostrovsky wrote:
>>>>> On 11/20/2017 06:50 AM, Jan Beulich wrote:
>>>>>>>>> On 20.11.17 at 12:20, <jgross@xxxxxxxx> wrote:
>>>>>>> Which restriction? I'm loading the RSDP table to its architectural
>>>>>>> correct addres if possible, otherwise it will be loaded to the same
>>>>>>> address as without my patch. So I'm not adding a restriction, but
>>>>>>> removing one.
>>>>>> What is "architecturally correct" in PVH can't be read out of
>>>>>> specs other than what we write down. When there's no BIOS,
>>>>>> placing anything right below the 1Mb boundary is at least
>>>>>> bogus.
>>>>>
>>>>> Unless it's a UEFI boot -- where else would you put it? Aren't these two
>>>>> (UEFI and non-UEFI) the only two options that the ACPI spec provides?
>>>>
>>>> I think Jan is right: for PVH its _our_ job to define the correct
>>>> placement. Which still can be the same as in the BIOS case, making
>>>> it easier to adapt any guest systems.
>>>>
>>>> So I'd say: The RSDP address in PVH case is passed in the PVH start
>>>> info block to the guest. In case there is no conflict with the
>>>> physical load address of the guest kernel the preferred address of
>>>> the RSDP is right below the 1MB boundary.
>>>>
>>>> Would this wording be okay?
>>>
>>> To be honest (and in case it wasn't sufficiently clear form my
>>> earlier replies) - I'm pretty much opposed to this below-1Mb thing.
>>> There ought to be just plain RAM there for PVH.
>>
>> So without my patch the RSDP table is loaded e.g. at about 6.5MB when
>> I'm using grub2 (the loaded grub image is about 5.5MB in size and it
>> is being loaded at 1MB).
>>
>> When I'm using the PVH Linux kernel directly RSDP is just below 1MB
>> due to pure luck (the bzImage loader is still using the PV specific
>> ELF notes and this results in the loader believing RSDP is loadable
>> at this address, which is true, but the tests used to come to this
>> conclusion are just not applicable for PVH).
>>
>> So in your opinion we should revoke the PVH support from Xen 4.10,
>> Linux and maybe BSD because RSDP is loaded in middle of RAM of the
>> guest?
> 
> So what's wrong with it being put wherever the next free memory
> location is being determined to be by the loader, just like is being
> done for other information, including modules (if any)?

The RSDP table is marked as "Reserved" in the memory map. So putting it
somewhere in the middle of the guest's memory will force the guest to
use 4kB pages instead of 2MB or even 1GB pages. I'd really like to avoid
this problem, as we've been hit by the very same in HVM guests before
causing quite measurable performance drops.

So I'd rather put it in the first MB as most kernels have to deal with
small pages at beginning of RAM today. An alternative would be to put
it just below 4GB where e.g. the console and Xenstore page are located.

> 
>> Doing it in a proper way you are outlining above would render
>> current PVH guests unusable.
> 
> I'm afraid I don't understand which outline of mine you refer to.
> Iirc all I said was that placing it below 1Mb is bogus. Top of RAM
> (as I think I saw being mentioned elsewhere) probably isn't much
> better. Special locations should be used only if there's really no
> other way to convey information.

I believe it is better to define where reserved memory areas are located
in order to make it easier for a kernel to deal with the consequences. A
location like "somewhere in memory, either just after the loaded kernel,
or after the boot loader which was loaded previously" seems not to be a
proper solution. Especially as a change in size of the boot loader could
make it impossible to load the kernel at the desired location, as this
would contradict the information returned by the hypervisor in the
memory map.


Juergen

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