On Tue, Jul 6, 2021 at 5:05 PM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > 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. 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
