Re: [PATCH 03/16] KVM-HDR: KVM Userspace registering ioctl

From: Avi Kivity
Date: Wed Jan 26 2011 - 10:14:32 EST

On 01/26/2011 02:14 PM, Glauber Costa wrote:
On Wed, 2011-01-26 at 13:12 +0200, Avi Kivity wrote:
> On 01/24/2011 08:06 PM, Glauber Costa wrote:
> > KVM, which stands for KVM Virtual Memory (I wanted to call it KVM Virtual Mojito),
> > is a piece of shared memory that is visible to both the hypervisor and the guest
> > kernel - but not the guest userspace.
> >
> > The basic idea is that the guest can tell the hypervisor about a specific
> > piece of memory, and what it expects to find in there. This is a generic
> > abstraction, that goes to userspace (qemu) if KVM (the hypervisor) can't
> > handle a specific request, thus giving us flexibility in some features
> > in the future.
> >
> > KVM (The hypervisor) can change the contents of this piece of memory at
> > will. This works well with paravirtual information, and hopefully
> > normal guest memory - like last update time for the watchdog, for
> > instance.
> >
> > This patch contains the header part of the userspace communication implementation.
> > Userspace can query the presence/absence of this feature in the normal way.
> > It also tells the hypervisor that it is capable of handling - in whatever
> > way it chooses, registrations that the hypervisor does not know how to.
> > In x86, only user so far, this mechanism is implemented as generic userspace
> > msr exit, that could theorectically be used to implement msr-handling in
> > userspace.
> >
> > I am keeping the headers separate to facilitate backports to people
> > who wants to backport the kernel part but not the hypervisor, or the other way around.
> >
> Again the protocol is not specified. How about starting from
> Documentation/kvm/api.txt so we don't have to guess?
I will do that in the next version, if the idea is not shoot up

For some reason people write the code first and the documentation as an afterthought. If you switch the order, you can get a high level review first, followed by a low-level code review once the high level details are agreed. Of course it's hard to do major changes this way, since the API often evolves while writing the code.

error compiling committee.c: too many arguments to function

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at