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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 11/20/2017 09:36 AM, Andrew Cooper wrote:
> On 20/11/17 14:25, Boris Ostrovsky wrote:
>> On 11/20/2017 09:14 AM, Juergen Gross 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. 
>> Yes, and if it is placed in a non-standard location then the guest will
>> have to deal with it in a non-standard way. Which we can in Linux by
>> setting acpi_rsdp pointer in the special PVH entry point, before jumping
>> to Linux "standard" entry --- startup_{32|64}().
>>
>> But if your goal is to avoid that special entry point (and thus not set
>> acpi_rsdp) then how do you expect kernel to find RSDP?
>>
>>> 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.
>> And what do we do if there *is* a conflict?
> As a random alternative, what about writing up an RSDP reference into
> the zeropage?

zeropage is an ABI with no provision for ACPI.

>
> I'd be surprised if Xen PVH is the only software in this position of
> trying to use the native paths wherever possible, and not retaining
> legacy ideas of a PC system.


I am not aware of any other guests that completely avoid legacy stuff.
But as I mentioned in another reply, KVM people may be looking at this
as well now.

-boris

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