On 06/07/21 21:52, Eduardo Habkost wrote:
On Wed, Jun 09, 2021 at 02:14:39PM -0700, Pawan Gupta wrote:
On CPUs that deprecated TSX, clearing the enumeration bits CPUID.RTM and
CPUID.HLE may not be desirable in some corner cases. Like a saved guest
would refuse to resume if it was saved before the microcode update
that deprecated TSX.
Why is a global option necessary to allow those guests to be
resumed? Why can't KVM_GET_SUPPORTED_CPUID always return the HLE
and RTM bits as supported when the host CPU has them?
It's a bit tricky, because HLE and RTM won't really behave well. An old
guest that sees RTM=1 might end up retrying and aborting transactions
too much. So I'm not sure that a QEMU "-cpu host" guest should have HLE
and RTM enabled.
So it makes sense to handle it in userspace, with one of the two
following possibilities:
- userspace sees TSX_FORCE_ABORT and if so it somehow "discourages"
setting HLE/RTM, even though they are shown as supported
- userspace sees TSX_FORCE_ABORT and if so it knows HLE/RTM can be set,
even though they are discouraged in general
In any case, KVM's "supported CPUID" is based on the host features but
independent. KVM can decide to show or hide the hardware HLE and RTM
bits independent of the host tsx= setting; it may make sense to hide the
bits via a module parameter, but in any case this patch is not needed.
Paolo
