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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.11.17 at 09:13, <jgross@xxxxxxxx> wrote:
> On 21/11/17 08:50, Jan Beulich wrote:
>>>>> On 20.11.17 at 19:28, <jgross@xxxxxxxx> wrote:
>>> On 20/11/17 17:14, Jan Beulich wrote:
>>>>>>> On 20.11.17 at 16:24, <jgross@xxxxxxxx> wrote:
>>>>> 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.
>> 
>> This is a valid point.
>> 
>>> 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.
>> 
>> Putting it in the first Mb implies that mappings there will continue to
>> be 4k ones. I can't, however, see why for PVH that should be
>> necessary: There's no BIOS and nothing legacy that needs to live
>> there, so other than HVM it could benefit from using a 1Gb mapping
>> even at address zero (even if this might be something that can't
>> be achieved right away). So yes, if anything, the allocation should
>> be made top down starting from 4Gb. Otoh, I don't see a strict
>> need for this area to live below 4Gb in the first place.
> 
> The physical RSDP address in the PVH start info block is 32 bits
> only. So it can't be above 4GB.

struct hvm_start_info {
    uint32_t magic;             /* Contains the magic value 0x336ec578       */
                                /* ("xEn3" with the 0x80 bit of the "E" set).*/
    uint32_t version;           /* Version of this structure.                */
    uint32_t flags;             /* SIF_xxx flags.                            */
    uint32_t nr_modules;        /* Number of modules passed to the kernel.   */
    uint64_t modlist_paddr;     /* Physical address of an array of           */
                                /* hvm_modlist_entry.                        */
    uint64_t cmdline_paddr;     /* Physical address of the command line.     */
    uint64_t rsdp_paddr;        /* Physical address of the RSDP ACPI data    */
                                /* structure.                                */
};

Granted a comment a few lines up in the public header says "NB: Xen
on x86 will always try to place all the data below the 4GiB boundary."

Jan


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