Re: [PATCH RFC 2/3] xen/hvm: introduce a fpu_initialised filed to the CPU save record

["Roger Pau Monné" <roger.pau@citrix.com>]

El 14/10/15 a les 18.51, Andrew Cooper ha escrit:
> On 14/10/15 17:24, Roger Pau Monne wrote:
>> Introduce a new filed to signal if the FPU has been initialised or not. Xen
> 
> "field", I am guessing?

Yes.

>> diff --git a/xen/include/public/arch-x86/hvm/save.h b/xen/include/public/arch-x86/hvm/save.h
>> index c7560f2..c4863be 100644
>> --- a/xen/include/public/arch-x86/hvm/save.h
>> +++ b/xen/include/public/arch-x86/hvm/save.h
>> @@ -47,7 +47,8 @@ DECLARE_HVM_SAVE_TYPE(HEADER, 1, struct hvm_save_header);
>>  /*
>>   * Processor
>>   *
>> - * Compat: Pre-3.4 didn't have msr_tsc_aux
>> + * Compat2: Pre-4.7 didn't have fpu_initialised
>> + * Compat1: Pre-3.4 didn't have msr_tsc_aux
> 
> I would suggest reversing the Compat1 and 2 lines, to match chronology.

OK, that's fine.

>>   */
>>  
>>  struct hvm_hw_cpu {
>> @@ -157,9 +158,121 @@ struct hvm_hw_cpu {
>>      };
>>      /* error code for pending event */
>>      uint32_t error_code;
>> +    /* is fpu initialised? */
>> +    uint8_t fpu_initialised:1;
> 
> Bitfields can't be used in the public ABI, and please don't leave
> trailing implicit padding.

Sadly we already have quite a lot of bitfields in the same file (see
hvm_hw_vpic) but I understand why they shouldn't be used, specially if
we do the versioning based on the size of the structure.

> I would recommend uint32_t flags and specify that bit 0 indicates that
> fpu context is initialised.

Right.

Roger.