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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
