Re: [PATCH -v2] kvm: Emulate MOVBE

[Gleb Natapov <gleb@redhat.com>]

On Fri, Apr 19, 2013 at 12:48:48AM +0200, Borislav Petkov wrote:
> On Wed, Apr 17, 2013 at 04:02:00PM +0200, Borislav Petkov wrote:
> > Right, so basically we want to handle features which were explicitly
> > enabled only for this guest as private, only relevant to this
> > particular guest run.
> 
> Ok,
> 
> here are two more ideas Joerg and I had today during lunch:
> 
> * reuse KVM_GET_SUPPORTED_CPUID
> 
> we hand-in a struct kvm_cpuid_entry2 with ->function and respective bits
> in e[abcd]x set for each CPUID leaf we want to query kvm.
> 
> Once in the kernel, we do the following:
> 
> if ->function is not 0xffffffff, it means userspace wants us to look at
> the all set bits in the respective e[abcd]x members.
There may be userspaces that set ->function to 0xffffffff (just because
they do not init the buffer before calling into the kernel) and this will
break them.

> 
> For each set bit, we check whether we emulate the respective feature
> and if so, we leave it untouched before returning it to userspace.
> Otherwise, we clear it before OR-ing in the host bits and the
> good-emulated bits like x2apic.
> 
> Yeah, semantics need to be handled carefully, but it has this
> knock-on-door aspect where kvm says that it actually emulates a feature
> only if asked, i.e. with the -cpu ...,+<feature> syntax.
> 
> * new ioctl KVM_GET_EMULATED_CPUID
> 
> Might be overkill and might be used only in a limited fashion since we
> don't want to emulate *every* feature in kvm.
> 
> Hmmm. I kinda like the first one more while the second one is cleaner.
> 
The first one needs explicit userspace support to work correctly. This
should be other way around: old userspace should do the right thing, but may
not support new features, new userspace should be able to support new
feature.

We may extend KVM_GET_SUPPORTED_CPUID instead of adding new one. There
is a padding field in kvm_cpuid2 that we could have reused as flags,
but unfortunately current implementation does not error if the field is
not zero, so if there is a userspace that does not zero the padding it may
break. Another options is to reuse high bits of nent as flags (not very
nice, but will work).

--
			Gleb.