On Thu, Jul 07, 2016 at 01:27:55PM -0300, Eduardo Habkost wrote: > You mean KVM kernel patches? No, other ones. Here's one example: https://lkml.kernel.org/r/1467633035-32080-2-git-send-email-Yazen.Ghannam@xxxxxxx > I assume the features require additional KVM code to support them > in guests. In that case, why wouldn't the kernel return them in > GET_SUPPORTED_CPUID? Then you won't need filter=off. Yeah, so in most cases they will need additional KVM code to enable them. More often than not, this is not always at the top of the TODO list of people so ... That's why I did the quick thing of smoke-testing them by enabling only CPUID bits and the filter=off thing. Would it be nicer to see them actually implemented in qemu/kvm? Definitely. > About filter=off: not sure. Do we really have valid use cases to > enable a feature even if the kernel reports it as unsupported in > GET_SUPPORTED_CPUID? Yeah, as said above, the filter=off thing was a dirty hack just to stop x86_cpu_filter_features() from checking whether the host supports them or not. > Do those features introduce additional state that need migration > support? If they do, you need to add them to > feature_word_info[FEAT_8000_0007_EBX].unmigratable_flags until > migration support is implemented. I'm afraid you'd need to explain migration support to me: is the question whether migrating the guest to an Intel platform and whether the features would still work? Because those three above are AMD-only and they won't work on an Intel platform. And if so, I'm guessing they should always remain unmigratable. Which is not a problem as there are Intel features which are not present on AMD so... Thanks! -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html