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.
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.
Opinions?
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
