> On 21 Aug 2019, at 23:59, Jim Mattson <jmattson@xxxxxxxxxx> 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! What happens if the guest tries to use HLT activity state regardless of the bit? Currently in KVM the guest will succeed, since there are no checks on VM entry for that. I previously submitted a patch[1] that adds a check for that, what do you think about it? [1] https://patchwork.kernel.org/patch/11092209/ Nikita
