Re: [PATCH 14/15] KVM: Add support for enabling capabilities per-vcpu

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/08/2010 04:18 PM, Alexander Graf wrote:
Avi Kivity wrote:
On 03/08/2010 04:10 PM, Alexander Graf wrote:
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?

Exactly, we do so in several places.  Can be useful if, for example,
some new capability comes with a resource count value.

What's this thing anyway?  like cpuid bits for x86?
What thing? This ioctl or the OSI call?

The ioctl is a way to enable a feature on a per-vcpu basis. MOL overlays
the syscall interface with a hypercall interface, so a normal OS syscall
magically becomes a hypercall when magic constants get passed in r3 and r4.

Because for obvious reasons we don't want to enable that when not using
MOL, I figured I'd go in and have userspace decide if it wants to get a
hypercall exit or not. Qemu couldn't really do anything with it after
all. And while at it, I figured let's better make the interface generic.

That's reasonable.  Thanks.

--
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

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux