Re: [Xen-devel] [PATCH v2 1/6] public/xen.h: add flags field to vcpu_time_info

[Joao Martins <joao.m.martins@xxxxxxxxxx>]

On 03/31/2016 08:13 AM, Jan Beulich wrote:
>>>> On 29.03.16 at 15:44, <joao.m.martins@xxxxxxxxxx> wrote:
>> This field has two possible flags (as of latest pvclock ABI
>> shared with KVM).
>>
>> flags: bits in this field indicate extended capabilities
>> coordinated between the guest and the hypervisor.  Specifically
>> on KVM, availability of specific flags has to be checked in
>> 0x40000001 cpuid leaf. On Xen, we don't have that but we can
>> still check some of the flags after registering the time info
>> page since a force_update_vcpu_system_time is performed.
>>
>> Current flags are:
>>
>>  flag bit   | cpuid bit    | meaning
>> -------------------------------------------------------------
>>             |              | time measures taken across
>>      0      |      24      | multiple cpus are guaranteed to
>>             |              | be monotonic
>> -------------------------------------------------------------
>>             |              | guest vcpu has been paused by
>>      1      |     N/A      | the host
>>             |              |
>> -------------------------------------------------------------
>>
>> Signed-off-by: Joao Martins <joao.m.martins@xxxxxxxxxx>
> 
> With one further adjustment (which could be done while committing)
> Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
Thanks!

>> --- a/xen/include/public/xen.h
>> +++ b/xen/include/public/xen.h
>> @@ -614,10 +614,14 @@ struct vcpu_time_info {
>>       */
>>      uint32_t tsc_to_system_mul;
>>      int8_t   tsc_shift;
>> -    int8_t   pad1[3];
>> +    uint8_t  flags;
>> +    uint8_t  pad1[2];
>>  }; /* 32 bytes */
>>  typedef struct vcpu_time_info vcpu_time_info_t;
>>  
>> +#define PVCLOCK_TSC_STABLE_BIT      (1 << 0)
>> +#define PVCLOCK_GUEST_STOPPED       (1 << 1)
I noticed from seeing different indentation on Jan's reply that there should be
spaces and no tabs here between the macro name and value. Fixed that too.

> No new identifiers not properly prefixed by XEN_ (or, elsewhere,
> xen_) in the canonical public headers please (whether
> downstream consumers like Linux elect to strip such prefixes is
> an independent aspect).
> 
OK, fixed and note taken.

If desired, I can submit v3 of this one in separate if Ian J. would like it
committed beforehand. Though what's added here, only get used later on this 
series.

João

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