2017-03-22 0:45 GMT+08:00 Radim Krčmář <rkrcmar@xxxxxxxxxx>: > 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. I observed that the hang during the boot of guest since pvspinlock depends on trapping the halt as mentioned in this patch: http://lkml.iu.edu/hypermail/linux/kernel/1202.0/03309.html，the hang disappears when I remove the KVM_FEATURE_PV_UNHALT CPUID flag in order to disable the pvspinlock in guest from kvm. So if disable the pvspinlock in the low latency scenario(idle=poll in guest) w/ vCPU and pCPU 1:1 pin can be acceptable? Regards, Wanpeng Li
