> Here I'm less certain what the best approach is. As you point out, > there's an inconsistency that I agree should be fixed. I wonder however > whether an approach similar to 3/6 for KVM only would be better? I.e., > have VMX as a sometimes-KVM-supported feature be listed in the model and > filter it out for accel=kvm so that -cpu enforce works, but let > accel=tcg fail with features not implemented.
This would mean that -cpu coreduo,enforce doesn't work on TCG, but -cpu Nehalem,enforce works. This does not make much sense to me. In fact, I would even omit the x86_cpu_compat_set_features altogether. The inclusion of vmx in these models was a mistake, and nested VMX is not really useful with anything but "-cpu host" because there are too many capabilities communicated via MSRs rather than CPUID. Paolo -- 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
