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

[Juergen Gross <jgross@xxxxxxxx>]

On 21/11/17 09:46, Jan Beulich wrote:
>>>> 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.                                
> */
> };

Oh, it seems I have been looking into an outdated document. Thanks for
the correction.

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

Okay.


Juergen

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