On Tue, Jul 6, 2021 at 5:05 PM Paolo Bonzini [off-list ref] wrote:

On 06/07/21 21:52, Eduardo Habkost wrote:

quoted

On Wed, Jun 09, 2021 at 02:14:39PM -0700, Pawan Gupta wrote:

quoted

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.

Is the purpose of GET_SUPPORTED_CPUID to return what is supported by
KVM, or to return what "-cpu host" should enable by default? They are
conflicting requirements in this case.

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 either case, we can make new userspace behave well. I'm worried
about existing userspace:

Returning HLE=1,RTM=1 in GET_SUPPORTED_CPUID makes existing userspace
take bad decisions until it's updated.

Returning HLE=0,RTM=0 in GET_SUPPORTED_CPUID prevents existing
userspace from resuming existing VMs (despite being technically
possible).

The first option has an easy workaround that doesn't require a
software update (disabling HLE/RTM in the VM configuration). The
second option doesn't have a workaround. I'm inclined towards the
first option.

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

-- 
Eduardo