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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 21/11/17 09:37, Juergen Gross wrote:
> 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.

The 4GB limit is specifically because we don't know a priori whether it
is a 32 or 64bit guest, and we agreed not to put the tables anywhere you
couldn't reach with paging disabled.

~Andrew

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