From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Date: Mon, 08 Mar 2010 13:56:33 +0000 Subject: Re: [PATCH 14/15] KVM: Add support for enabling capabilities per-vcpu Message-Id: <4B950211.5010505@suse.de> List-Id: References: <1267807842-3751-1-git-send-email-agraf@suse.de> <1267807842-3751-15-git-send-email-agraf@suse.de> <4B950057.1090204@redhat.com> <4B9500D1.2060008@suse.de> <4B95012B.3030505@redhat.com> In-Reply-To: <4B95012B.3030505-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Avi Kivity Cc: kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Avi Kivity wrote: > On 03/08/2010 03:51 PM, Alexander Graf wrote: >> Avi Kivity wrote: >> >>> On 03/05/2010 06:50 PM, Alexander Graf wrote: >>> >>>> } >>>> diff --git a/include/linux/kvm.h b/include/linux/kvm.h >>>> index ce28767..c7ed3cb 100644 >>>> --- a/include/linux/kvm.h >>>> +++ b/include/linux/kvm.h >>>> @@ -400,6 +400,12 @@ struct kvm_ioeventfd { >>>> __u8 pad[36]; >>>> }; >>>> >>>> +/* for KVM_ENABLE_CAP */ >>>> +struct kvm_enable_cap { >>>> + /* in */ >>>> + __u32 cap; >>>> >>>> >>> Reserve space here. Add a flags field and check it for zeros. >>> >> Flags? How about something like >> >> u64 args[4] >> >> That way the capability enabling code could decide what to do with the >> arguments. We don't always only need flags I suppose?. >> > > If you interpret these as bit flags anyway, that would be redundant. > I think I just don't understand what you're trying to say with "flags". For the OSI enabling we don't need any flags. For later additions we don't know what we'll need. Alex From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Subject: Re: [PATCH 14/15] KVM: Add support for enabling capabilities per-vcpu Date: Mon, 08 Mar 2010 14:56:33 +0100 Message-ID: <4B950211.5010505@suse.de> References: <1267807842-3751-1-git-send-email-agraf@suse.de> <1267807842-3751-15-git-send-email-agraf@suse.de> <4B950057.1090204@redhat.com> <4B9500D1.2060008@suse.de> <4B95012B.3030505@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Avi Kivity Return-path: In-Reply-To: <4B95012B.3030505-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Sender: kvm-ppc-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: kvm.vger.kernel.org Avi Kivity wrote: > On 03/08/2010 03:51 PM, Alexander Graf wrote: >> Avi Kivity wrote: >> >>> On 03/05/2010 06:50 PM, Alexander Graf wrote: >>> >>>> } >>>> diff --git a/include/linux/kvm.h b/include/linux/kvm.h >>>> index ce28767..c7ed3cb 100644 >>>> --- a/include/linux/kvm.h >>>> +++ b/include/linux/kvm.h >>>> @@ -400,6 +400,12 @@ struct kvm_ioeventfd { >>>> __u8 pad[36]; >>>> }; >>>> >>>> +/* for KVM_ENABLE_CAP */ >>>> +struct kvm_enable_cap { >>>> + /* in */ >>>> + __u32 cap; >>>> >>>> >>> Reserve space here. Add a flags field and check it for zeros. >>> >> Flags? How about something like >> >> u64 args[4] >> >> That way the capability enabling code could decide what to do with the >> arguments. We don't always only need flags I suppose?. >> > > If you interpret these as bit flags anyway, that would be redundant. > I think I just don't understand what you're trying to say with "flags". For the OSI enabling we don't need any flags. For later additions we don't know what we'll need. Alex