From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 14/15] KVM: Add support for enabling capabilities per-vcpu Date: Mon, 08 Mar 2010 16:02:42 +0200 Message-ID: <4B950382.8010609@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm-ppc@vger.kernel.org, kvm@vger.kernel.org To: Alexander Graf Return-path: Received: from mx1.redhat.com ([209.132.183.28]:26146 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754279Ab0CHOCr (ORCPT ); Mon, 8 Mar 2010 09:02:47 -0500 In-Reply-To: <4B950211.5010505@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: 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. -- error compiling committee.c: too many arguments to function