2017-03-21 14:21+0800, Wanpeng Li: > 2017-03-21 9:47 GMT+08:00 Longpeng (Mike) <longpeng2@xxxxxxxxxx>: >> 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.
