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
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/