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 15:10:42 +0100 Message-ID: <4B950562.6050509@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> <4B950211.5010505@suse.de> <4B950382.8010609@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kvm-ppc@vger.kernel.org, kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from cantor.suse.de ([195.135.220.2]:55632 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755027Ab0CHOKo (ORCPT ); Mon, 8 Mar 2010 09:10:44 -0500 In-Reply-To: <4B950382.8010609@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > On 03/08/2010 03:56 PM, Alexander Graf wrote: >> 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. >> > > When we have reserved fields which are later used for something new, > the kernel needs a way to know if the reserved fields are known or not > by userspace. One way to do this is to assume a value of zero means > the field is unknown to usespace so ignore it. Another is to require > userspace to set a bit in an already-known flags field, and only act > on the new field if its bit was set. This has the advantage that the > old kernel checks for unknown flags and errors out, improving forwards > and backwards compatibility. > > I thought ->cap was already a bit field, so this isn't necessary, but > if it isn't, then a flags field is helpful. -> cap is the capability number. So you want something like: struct kvm_enable_cap { __u32 cap; __u32 flags; __u64 args[4]; __u8 pad[64]; }; And then check for flags == 0 in the ioctl handler? Flags could later on define if the padding changed to a different position, adding new fields in between args and pad? Alex