From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Wed, 04 Jan 2012 19:25:33 +0000 Subject: Re: [PATCH 1/2] KVM: PPC: epapr: Add idle hcall support for host Message-Id: <4F04A7AD.80907@freescale.com> List-Id: References: <1325312176-17697-1-git-send-email-yu.liu@freescale.com> <4F030A51.3020309@redhat.com> <4F042B11.1080104@redhat.com> <1F66722B-9268-4E3D-874A-1F24BC341F79@suse.de> In-Reply-To: <1F66722B-9268-4E3D-874A-1F24BC341F79@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Alexander Graf Cc: Avi Kivity , Liu Yu , "kvm-ppc@vger.kernel.org" , "kvm@vger.kernel.org" On 01/04/2012 06:04 AM, Alexander Graf wrote: > > > On 04.01.2012, at 11:33, Avi Kivity 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [PATCH 1/2] KVM: PPC: epapr: Add idle hcall support for host Date: Wed, 4 Jan 2012 13:25:33 -0600 Message-ID: <4F04A7AD.80907@freescale.com> References: <1325312176-17697-1-git-send-email-yu.liu@freescale.com> <4F030A51.3020309@redhat.com> <4F042B11.1080104@redhat.com> <1F66722B-9268-4E3D-874A-1F24BC341F79@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Avi Kivity , Liu Yu , "kvm-ppc@vger.kernel.org" , "kvm@vger.kernel.org" To: Alexander Graf Return-path: In-Reply-To: <1F66722B-9268-4E3D-874A-1F24BC341F79@suse.de> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 01/04/2012 06:04 AM, Alexander Graf wrote: > > > On 04.01.2012, at 11:33, Avi Kivity 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