Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX

[Borislav Petkov <bp@alien8.de>]

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@amd.com

> 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.