Re: [PATCH 1/2] KVM: PPC: epapr: Add idle hcall support for host

[Scott Wood <scottwood@freescale.com>]

On 01/04/2012 06:04 AM, Alexander Graf wrote:
> 
> 
> On 04.01.2012, at 11:33, Avi Kivity <avi@redhat.com> wrote:
> 
>> On 01/03/2012 04:13 PM, Alexander Graf wrote:
>>> On 03.01.2012, at 15:01, Avi Kivity wrote:
>>>
>>>> On 12/31/2011 08:16 AM, Liu Yu wrote:
>>>>> Add a new field opt_feature in struct kvm_ppc_pvinfo
>>>>> to tell userspace whether it support hcall idle.
>>>>>
>>>>> diff --git a/include/linux/kvm.h b/include/linux/kvm.h
>>>>> index c107fae..5af21f3 100644
>>>>> --- a/include/linux/kvm.h
>>>>> +++ b/include/linux/kvm.h
>>>>> @@ -426,9 +426,12 @@ struct kvm_ppc_pvinfo {
>>>>>    /* out */
>>>>>    __u32 flags;
>>>>>    __u32 hcall[4];
>>>>> -    __u8  pad[108];
>>>>> +    __u32 opt_features;
>>>>> +    __u8  pad[104];
>>>>> };
>>>>>
>>>>> +#define KVM_PPC_PVINFO_HAS_EV_IDLE   (1<<0)
>>>>> +
>>>>>
>>>>
>>>> Needs to be documented, plus a KVM_CAP so userspace can discover that
>>>> this feature is available,
>>>
>>> Not if we put the bit into flags. Then user space can just check the flags bitmap and know that it's there regardless of capabilities, because older kernels will set the bit to 0.
>>
>> It needs to detect that opt_features is available during compile time
>> (qemu copies headers, but we don't want to force everyone to do that).
> 
> The point is that we don't need opt_features. We already have a fearure bitmap in the struct.

Even if we did for whatever reason want a new field, the entire struct
is zeroed currently, so we only need a flag if we need to distinguish
"field is zero" from "field is not valid".

-Scott