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

From: Avi Kivity <avi@redhat.com>
To: Glauber Costa <glommer@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, aliguori@us.ibm.com
Subject: Re: [PATCH 01/16] KVM-HDR: register KVM basic header infrastructure
Date: Wed, 26 Jan 2011 17:12:11 +0200	[thread overview]
Message-ID: <4D4039CB.6060008@redhat.com> (raw)
In-Reply-To: <1296044013.15920.47.camel@mothafucka.localdomain>

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?

Yes.

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