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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

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.

-boris

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