On Wed, Aug 21, 2019 at 3:22 PM Sean Christopherson <sean.j.christopherson@xxxxxxxxx> wrote: > > On Wed, Aug 21, 2019 at 01:59:20PM -0700, Jim Mattson wrote: > > On Mon, Aug 19, 2019 at 3:11 PM Sean Christopherson > > <sean.j.christopherson@xxxxxxxxx> wrote: > > > > > > On Tue, Aug 20, 2019 at 12:46:49AM +0300, Nikita Leshenko wrote: > > > > Before this commit, userspace could disable the GUEST_ACTIVITY_HLT bit in > > > > VMX_MISC yet KVM would happily accept GUEST_ACTIVITY_HLT activity state in > > > > VMCS12. We can fix it by either failing VM entries with HLT activity state when > > > > it's not supported or by disallowing clearing this bit. > > > > > > > > The latter is preferable. If we go with the former, to disable > > > > GUEST_ACTIVITY_HLT userspace also has to make CPU_BASED_HLT_EXITING a "must be > > > > 1" control, otherwise KVM will be presenting a bogus model to L1. > > > > > > > > Don't fail writes that disable GUEST_ACTIVITY_HLT to maintain backwards > > > > compatibility. > > > > > > Paolo, do we actually need to maintain backwards compatibility in this > > > case? This seems like a good candidate for "fix the bug and see who yells". > > > > Google's userspace clears bit 6. Please don't fail that write! > > Booooo. > Supporting activity state HLT is on our list of things to do, but I'm not convinced that kvm actually handles it properly yet. For instance... What happens if L1 launches L2 into activity state HLT with a zero-valued VMX preemption timer? (Maybe this is fixed now?) What happens if "monitor trap flag" is set and "HLT exiting" is clear in the vmcs12, and immediately on VM-entry, L2 executes HLT? (Yes, this is a special case of MTF being broken when L0 emulates an L2 instruction.) I'm sure there are other interesting scenarios that haven't been validated.
