From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 13/15] KVM: Add support for enabling capabilities per-vcpu Date: Tue, 09 Mar 2010 15:09:18 +0200 Message-ID: <4B96487E.5060100@redhat.com> References: <1268071402-27112-1-git-send-email-agraf@suse.de> <1268071402-27112-14-git-send-email-agraf@suse.de> <4B964593.1020406@redhat.com> <2CBC3D25-CD0A-4090-8177-E1FD5022A155@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]:27999 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752376Ab0CINJW (ORCPT ); Tue, 9 Mar 2010 08:09:22 -0500 In-Reply-To: <2CBC3D25-CD0A-4090-8177-E1FD5022A155@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: On 03/09/2010 03:01 PM, Alexander Graf wrote: > On 09.03.2010, at 13:56, Avi Kivity wrote: > > >> On 03/08/2010 08:03 PM, Alexander Graf wrote: >> >>> Some times we don't want all capabilities to be available to all >>> our vcpus. One example for that is the OSI interface, implemented >>> in the next patch. >>> >>> In order to have a generic mechanism in how to enable capabilities >>> individually, this patch introduces a new ioctl that can be used >>> for this purpose. That way features we don't want in all guests or >>> userspace configurations can just not be enabled and we're good. >>> >>> >>> diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt >>> index d170cb4..6a19ab6 100644 >>> --- a/Documentation/kvm/api.txt >>> +++ b/Documentation/kvm/api.txt >>> @@ -749,6 +749,21 @@ Writes debug registers into the vcpu. >>> See KVM_GET_DEBUGREGS for the data structure. The flags field is unused >>> yet and must be cleared on entry. >>> >>> +4.34 KVM_ENABLE_CAP >>> + >>> +Capability: basic >>> >>> >> Capability: basic means that the feature was present in 2.6.22. Otherwise you need to specify the KVM_CAP_ that presents this feature. >> >> >>> +Architectures: all >>> >>> >>> >> But it's implemented for ppc only (other arches will get ENOTTY). >> > That was the whole idea behind it. if it fails it fails. Nothing we can do about it. If it succeeds - great. > If KVM_CAP_ENABLE_CAP is present, it means the KVM_ENABLE_CAP ioctl will not return ENOTTY (it may return EINVAL if wrong values are present). ENOTTY means not implemented. 'Architectures: all' means implemented. >>> +Not all extensions are enabled by default. Using this ioctl the application >>> +can enable an extension, making it available to the guest. >>> + >>> +On systems that do not support this ioctl, it always fails. On systems that >>> +do support it, it only works for extensions that are supported for enablement. >>> +As of writing this the only enablement enabled extenion is KVM_CAP_PPC_OSI. >>> >>> >> That needs to be documented. It also needs to be discoverable separately - we can have a kernel with KVM_ENABLE_CAP but without KVM_CAP_PPC_OSI. >> >> btw, KVM_CAP_PPC_OSI conflicts with the KVM_CAP_ namespace. Please choose another namespace. >> > Well I figured it'd be slick to have capabilities get enabled or disabled. That's the whole idea behind making it generic. If I wanted a specific interface I'd go in and create an ioctl ENABLE_OSI_INTERFACE. > Ah, I see. Well, that makes sense. Please document it. > But this way the detection if a capability exists can be done using the existing CAP detection. It can then be enabled using ENABLE_CAP. > Okay, I agree. -- error compiling committee.c: too many arguments to function