Re: [Xen-devel] [PATCH v2 4/4] tools/libacpi: announce that PVHv2 has no CMOS RTC in FADT

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 02/12/16 14:21, Boris Ostrovsky wrote:
> On 12/02/2016 09:06 AM, Andrew Cooper wrote:
>> On 02/12/16 13:48, Roger Pau Monne wrote:
>>> At the moment this flag is unconditionally set for PVHv2 domains. Note that
>>> using this boot flag requires that the FADT table revision is at least 5 
>>> (or any
>>> later version), so bump the current FADT version from 4 to 5 and add two new
>>> fields that will be unused.
>>>
>>> Reported-by: Jan Beulich <jbeulich@xxxxxxxx>
>>> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>>> ---
>>> Cc: Jan Beulich <jbeulich@xxxxxxxx>
>>> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>> Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
>>> Cc: Wei Liu <wei.liu2@xxxxxxxxxx>
>>> Cc: boris.ostrovsky@xxxxxxxxxx
>>> Cc: konrad.wilk@xxxxxxxxxx
>>> ---
>>> Ideally this should be somehow fetched from the emulation_flags set of 
>>> flags,
>>> but sadly there's no way for hvmloader (which runs in guest context) to 
>>> fetch
>>> this information. If at some point a rtc option is added to libxl, we 
>>> should see
>>> about passing it through to init_acpi_config in libxl_x86_acpi.c so that we 
>>> can
>>> then appropriately set this flag for PVHv2 guests.
>> (I forget if there is a good reason, but) why do we still have hvmloader
>> writing the ACPI tables for HVM guests?  We should consolidate on one
>> consistent way of making things like this happen.
> I think one of the reasons was that MMIO addresses (which are needed by
> the tables) are determined by hvmloader during runtime.
>
> It would be nice to do this in the toolstack because we also use this
> information in cacheattr_init() which appears to be the only reason why
> we need to bring all possible VCPUs up and then offlining them.

Ah yes.  This ties in with the other needs to actually know the proper
layout of the guest in one consistent location.

This can be fixed properly when the hypervisor is the one authoritative
source of guest-layout information.

Lets fudge it for now if we can; no point expending effort fixing a
corner case which is going to be fixed differently anyway.

~Andrew

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