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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 02.12.16 at 18:32, <roger.pau@xxxxxxxxxx> wrote:
> On Fri, Dec 02, 2016 at 10:20:59AM -0700, Jan Beulich wrote:
>> >>> On 02.12.16 at 14:48, <roger.pau@xxxxxxxxxx> wrote:
>> > @@ -436,7 +439,7 @@ struct acpi_20_slit {
>> >   * Table revision numbers.
>> >   */
>> >  #define ACPI_2_0_RSDP_REVISION 0x02
>> > -#define ACPI_2_0_FADT_REVISION 0x04
>> > +#define ACPI_2_0_FADT_REVISION 0x05
>> 
>> Do we really want to make this change unconditionally, rather than
>> only for PVH guests? I'm not sure which (older) OSes look at table
>> revisions (and may hence end up being incompatible), or whether
>> OSes may expect certain table versions together with certain base
>> ACPI versions. I think I had pointed out before that we really
>> should have the guest config file "acpi=" setting mean a version
>> number, and table revisions should then be selected according to
>> that base version. As that's a larger change, simply using one
>> fixed version for HVM and another for PVH would look fine to me.
> 
> I don't mind using different revision numbers for HVM and PVH, but that means 
> that we would need to also have two different structures, one for FADT 4.0 
> and 
> one for FADT 5.0, which is kind of redundant, or maybe play tricks with size 

I wouldn't call this "playing tricks" - using sizeof() or offsetof() there
depending on version doesn't seem all that tricky to me, and is
common practice elsewhere.

> and the checksum. Also the current FADT table strcuture is named 
> acpi_20_fadt, 
> which seems to have gotten out-of-sync with the version we are using (4).

Looks like so, yes. The header file's name has the same issue.

Jan


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