From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: [Question] About the behavior of HLT in VMX guest mode Date: Tue, 21 Mar 2017 17:45:57 +0100 Message-ID: <20170321164557.GB25540@potion> References: <58C64672.1070706@huawei.com> <20170315173254.GF14081@potion> <58C9F3A5.3090604@huawei.com> <20170316142340.GD14076@potion> <58CB727B.20902@huawei.com> <20170320151815.GA25540@potion> <58D0863D.4080001@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: "Longpeng (Mike)" , kvm , Gonglei , Paolo Bonzini To: Wanpeng Li Return-path: Received: from mx1.redhat.com ([209.132.183.28]:47860 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932740AbdCUQqC (ORCPT ); Tue, 21 Mar 2017 12:46:02 -0400 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 2017-03-21 14:21+0800, Wanpeng Li: > 2017-03-21 9:47 GMT+08:00 Longpeng (Mike) : >> 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.