On Wed, Jul 16, 2014 at 7:32 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > Il 16/07/2014 16:07, Andy Lutomirski ha scritto: > >> This patch has nothing whatsoever to do with how much I trust the CPU >> vs the hypervisor. It's for the enormous installed base of machines >> without RDRAND. > > > Ok. I think an MSR is fine, though I don't think it's useful for the guest > to use it if it already has RDRAND and/or RDSEED. > > >> > In any case, is there a matching QEMU patch somewhere? >> >> What QEMU change is needed? I admit I'm a bit vague on how QEMU and >> KVM cooperate here, but there's no state to save and restore. I guess >> that QEMU wants the ability to turn this on and off for migration. >> How does that work? I couldn't spot the KVM code that allows this >> type of control. > > > It is QEMU who decides the CPUID bits that are visible to the guest. By > default it blocks bits that it doesn't know about. You would need to add > the bit in the kvm_default_features and kvm_feature_name arrays. > > For migration, we have "versioned" machine types, for example pc-2.1. > Once the versioned machine type exists, blocking the feature is a one-liner > like > > x86_cpu_compat_disable_kvm_features(FEAT_KVM, KVM_FEATURE_NAME); > > Unfortunately, QEMU is in hard freeze, so you'd likely be the one creating > pc-2.2. This is a boilerplate but relatively complicated patch. But let's > cross that bridge when we'll reach it. For now, you can simply add the bit > to the two arrays above. > Done. NB: Patch 4 of this series is bad due to an asm constraint issue that I haven't figured out yet. I'll send a replacement once I get it working. *sigh* the x86 kernel loading code is a bit of a compilation mess. > Paolo -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
