Re: [PATCH 01/16] KVM-HDR: register KVM basic header infrastructure

From: Avi Kivity
Date: Wed Jan 26 2011 - 10:12:23 EST

On 01/26/2011 02:13 PM, Glauber Costa wrote:
> - it doesn't lend itself will to live migration. Extra state must be
> maintained in the hypervisor.
Yes, but can be queried at any time as well. I don't do it in this
patch, but this is explicitly mentioned in my TODO.

Using the existing method (MSRs) takes care of this, which reduces churn.

> - it isn't how normal hardware operates
Since we're trying to go for guest cooperation here, I don't really see
a need to stay close to hardware here.

For Linux there is not much difference, since we can easily adapt it. But we don't know the impact on other guests, and we can't refactor them. Staying close to precedent means it will be easier for other guests to work with a kvm host, if they choose.

> what's wrong with extending the normal approach of one msr per feature?

* It's harder to do discovery with MSRs. You can't just rely on getting
an error before the idts are properly setups. The way I am proposing
allow us to just try to register a memory area, and get a failure if we
can't handle it, at any time

Use cpuid to ensure that you won't get a #GP.

* To overcome the above, we had usually relied on cpuids. This requires
qemu/userspace cooperation for feature enablement

We need that anyway. The kernel cannot enable features on its own since that breaks live migration.

* This mechanism just bumps us out to userspace if we can't handle a
request. As such, it allows for pure guest kernel -> userspace
communication, that can be used, for instance, to emulate new features
in older hypervisors one does not want to change. BTW, maybe there is
value in exiting to userspace even if we stick to the
one-msr-per-feature approach?


I'm not 100% happy with emulating MSRs in userspace, but we can think about a mechanism that allows userspace to designate certain MSRs as handled by userspace.

Before we do that I'd like to see what fraction of MSRs can be usefully emulated in userspace (beyond those that just store a value and ignore it).

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