Re: [PATCH] x86: KVM: Add feature flag for AMD's FsGsKernelGsBaseNonSerializing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/4/23 09:58, Borislav Petkov wrote:
On Tue, Oct 03, 2023 at 07:44:51PM -0700, Jim Mattson wrote:
The business of declaring breaking changes to the architectural
specification in a CPUID bit has never made much sense to me.
How else should they be expressed then?

In some flaky PDF which changes URLs whenever the new corporate CMS gets
installed?

Or we should do f/m/s matching which doesn't make any sense for VMs?

Nothing *needs* to be done other than documenting this retroactive change to what constitutes architectural behavior. It's not a CPUID that can be queried to change behavior; the user can use CPUID to diagnose that something has broken, but the broken program cannot know in the first place that the CPUID bit exists.

I agree with Jim that it would be nice to have some bits from Intel, and some bits from AMD, that current processors always return as 1. Future processors can change those to 0 as desired.

Intel did something similar with VMX. They have a bunch of bits for which we don't know the meaning, but we know it is something that "right now always causes vmexits". Even if in the future you might be able to disable it, the polarity of the bit is the same as for all other vmexit controls.

Paolo




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux