Re: [Question] About the behavior of HLT in VMX guest mode

["Radim Krčmář" <rkrcmar@redhat.com>]

2017-03-21 14:21+0800, Wanpeng Li:
> 2017-03-21 9:47 GMT+08:00 Longpeng (Mike) <longpeng2@huawei.com>:
>> On 2017/3/20 23:18, Radim Krčmář wrote:
>>> 2017-03-17 13:22+0800, Longpeng (Mike):
>>>> Radim, how about to make HLT-exiting configurable again in upstream ? If you
>>>> like it, there is a problem should be resolved, asynpf is conflict with
>>>> "HLT-exiting = 0" in certain situations.
>>>
>>> Go ahead.  KVM should provide access to hardware features and
>>> no-HLT-exiting is reasonable as a per-VM (even per-VCPU if you make a
>>> good case) capability.  I'm interested in the asyncpf conflict.
> 
> After async pf setup successfully, there is a broadcast wakeup w/
> special token 0xffffffff which tells vCPU that it should wake up all
> processes waiting for APFs though there is no real process waiting at
> the moment.
> 
> Refer to SDM 26.3.1.5:
> 
> HLT. The only events allowed are the following:
> 
> — Those with interruption type external interrupt or non-maskable
> interrupt (NMI).
> — Those with interruption type hardware exception and vector 1 (debug
> exception) or vector 18 (machine-check exception).
> — Those with interruption type other event and vector 0 (pending MTF VM exit).
> 
> So if the guest activity state is hlt and delivery #PF event during
> vmentry, the vmentry will fail.

I see, so we also need to change the activity state to ACTIVE when
setting most interrupts in VM_ENTRY_INTR_INFO_FIELD ...
This adds overhead to the common case and gets a little tricky with
cancel_injection(), but should turn out to be bearable.

No word about GUEST_INTR_STATUS, so posted interrupts hopefully work
without additional changes.

> Refer to the original "KVM: VMX: add module parameter to avoid
> trapping HLT instructions"
> https://www.spinics.net/lists/kvm-commits/msg00137.html, it will set
> guest activity state to active if it is hlt before manually. Actually
> I wonder who set guest activity state to active when there is
> HLT-exiting.
> 
> In addition, what's your design for per-VM non HLT-exiting capability?

I would go with an enableable per-VM KVM_CAP_X86_GUEST_HLT that can be
used by userspace to set a variable in struct kvm.

Also, please take a look at SVM -- I think that errata #415 for family
0x10 forces us to introduce a vendor specific KVM_CHECK_EXTENSION and
KVM_ENABLE_CAP, because HLT must be intercepted in that case.

Thanks.