Re: [PATCH 13/15] KVM: Add support for enabling capabilities per-vcpu
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/15] KVM: Add support for enabling capabilities per-vcpu
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.
+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.
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.
Need to document the structure fields.
/*
@@ -696,6 +705,8 @@ struct kvm_clock_data {
/* Available with KVM_CAP_DEBUGREGS */
#define KVM_GET_DEBUGREGS _IOR(KVMIO, 0xa1, struct kvm_debugregs)
#define KVM_SET_DEBUGREGS _IOW(KVMIO, 0xa2, struct kvm_debugregs)
+/* No need for CAP, because then it just always fails */
+#define KVM_ENABLE_CAP_IOW(KVMIO, 0xa3, struct kvm_enable_cap)
The CAPs are needed so you can discover what you have without running guests.
The whole point of this extension was to make CAPs not always enabled, but make
them possibly enable on demand.
Alex--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/15] KVM: Add support for enabling capabilities per-vcpu
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).
+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.
Need to document the structure fields.
/*
@@ -696,6 +705,8 @@ struct kvm_clock_data {
/* Available with KVM_CAP_DEBUGREGS */
#define KVM_GET_DEBUGREGS _IOR(KVMIO, 0xa1, struct kvm_debugregs)
#define KVM_SET_DEBUGREGS _IOW(KVMIO, 0xa2, struct kvm_debugregs)
+/* No need for CAP, because then it just always fails */
+#define KVM_ENABLE_CAP_IOW(KVMIO, 0xa3, struct kvm_enable_cap)
The CAPs are needed so you can discover what you have without running guests.
--
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/15] KVM: Add support for enabling capabilities per-vcpu
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-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/15] KVM: Add support for enabling capabilities per-vcpu
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).
+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.
Need to document the structure fields.
/*
@@ -696,6 +705,8 @@ struct kvm_clock_data {
/* Available with KVM_CAP_DEBUGREGS */
#define KVM_GET_DEBUGREGS _IOR(KVMIO, 0xa1, struct kvm_debugregs)
#define KVM_SET_DEBUGREGS _IOW(KVMIO, 0xa2, struct kvm_debugregs)
+/* No need for CAP, because then it just always fails */
+#define KVM_ENABLE_CAP_IOW(KVMIO, 0xa3, struct kvm_enable_cap)
The CAPs are needed so you can discover what you have without running guests.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/15] KVM: Add support for enabling capabilities per-vcpu
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.
Signed-off-by: Alexander Graf ag...@suse.de
---
v1 - v2:
- Add flags to enable_cap
- Update documentation for kvm_enable_cap
---
Documentation/kvm/api.txt | 15 +++
arch/powerpc/kvm/powerpc.c | 26 ++
include/linux/kvm.h| 11 +++
3 files changed, 52 insertions(+), 0 deletions(-)
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
+Architectures: all
+Type: vcpu ioctl
+Parameters: struct kvm_enable_cap (in)
+Returns: 0 on success; -1 on error
+
+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.
+
5. The kvm_run structure
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index a28a512..8bd8204 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -462,6 +462,23 @@ int kvm_vcpu_ioctl_interrupt(struct kvm_vcpu *vcpu, struct
kvm_interrupt *irq)
return 0;
}
+static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,
+struct kvm_enable_cap *cap)
+{
+ int r;
+
+ if (cap-flags)
+ return -EINVAL;
+
+ switch (cap-cap) {
+ default:
+ r = -EINVAL;
+ break;
+ }
+
+ return r;
+}
+
int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
struct kvm_mp_state *mp_state)
{
@@ -490,6 +507,15 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
r = kvm_vcpu_ioctl_interrupt(vcpu, irq);
break;
}
+ case KVM_ENABLE_CAP:
+ {
+ struct kvm_enable_cap cap;
+ r = -EFAULT;
+ if (copy_from_user(cap, argp, sizeof(cap)))
+ goto out;
+ r = kvm_vcpu_ioctl_enable_cap(vcpu, cap);
+ break;
+ }
default:
r = -EINVAL;
}
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index ce28767..a18ac92 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -400,6 +400,15 @@ struct kvm_ioeventfd {
__u8 pad[36];
};
+/* for KVM_ENABLE_CAP */
+struct kvm_enable_cap {
+ /* in */
+ __u32 cap;
+ __u32 flags;
+ __u64 args[4];
+ __u8 pad[64];
+};
+
#define KVMIO 0xAE
/*
@@ -696,6 +705,8 @@ struct kvm_clock_data {
/* Available with KVM_CAP_DEBUGREGS */
#define KVM_GET_DEBUGREGS _IOR(KVMIO, 0xa1, struct kvm_debugregs)
#define KVM_SET_DEBUGREGS _IOW(KVMIO, 0xa2, struct kvm_debugregs)
+/* No need for CAP, because then it just always fails */
+#define KVM_ENABLE_CAP_IOW(KVMIO, 0xa3, struct kvm_enable_cap)
#define KVM_DEV_ASSIGN_ENABLE_IOMMU(1 0)
--
1.6.0.2
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/15] KVM: Add support for enabling capabilities per-vcpu
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.
Signed-off-by: Alexander Graf ag...@suse.de
---
v1 - v2:
- Add flags to enable_cap
- Update documentation for kvm_enable_cap
---
Documentation/kvm/api.txt | 15 +++
arch/powerpc/kvm/powerpc.c | 26 ++
include/linux/kvm.h| 11 +++
3 files changed, 52 insertions(+), 0 deletions(-)
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
+Architectures: all
+Type: vcpu ioctl
+Parameters: struct kvm_enable_cap (in)
+Returns: 0 on success; -1 on error
+
+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.
+
5. The kvm_run structure
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index a28a512..8bd8204 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -462,6 +462,23 @@ int kvm_vcpu_ioctl_interrupt(struct kvm_vcpu *vcpu, struct
kvm_interrupt *irq)
return 0;
}
+static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,
+struct kvm_enable_cap *cap)
+{
+ int r;
+
+ if (cap-flags)
+ return -EINVAL;
+
+ switch (cap-cap) {
+ default:
+ r = -EINVAL;
+ break;
+ }
+
+ return r;
+}
+
int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
struct kvm_mp_state *mp_state)
{
@@ -490,6 +507,15 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
r = kvm_vcpu_ioctl_interrupt(vcpu, irq);
break;
}
+ case KVM_ENABLE_CAP:
+ {
+ struct kvm_enable_cap cap;
+ r = -EFAULT;
+ if (copy_from_user(cap, argp, sizeof(cap)))
+ goto out;
+ r = kvm_vcpu_ioctl_enable_cap(vcpu, cap);
+ break;
+ }
default:
r = -EINVAL;
}
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index ce28767..a18ac92 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -400,6 +400,15 @@ struct kvm_ioeventfd {
__u8 pad[36];
};
+/* for KVM_ENABLE_CAP */
+struct kvm_enable_cap {
+ /* in */
+ __u32 cap;
+ __u32 flags;
+ __u64 args[4];
+ __u8 pad[64];
+};
+
#define KVMIO 0xAE
/*
@@ -696,6 +705,8 @@ struct kvm_clock_data {
/* Available with KVM_CAP_DEBUGREGS */
#define KVM_GET_DEBUGREGS _IOR(KVMIO, 0xa1, struct kvm_debugregs)
#define KVM_SET_DEBUGREGS _IOW(KVMIO, 0xa2, struct kvm_debugregs)
+/* No need for CAP, because then it just always fails */
+#define KVM_ENABLE_CAP_IOW(KVMIO, 0xa3, struct kvm_enable_cap)
#define KVM_DEV_ASSIGN_ENABLE_IOMMU(1 0)
--
1.6.0.2
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
