From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Longpeng (Mike)" Subject: Re: [Question] About the behavior of HLT in VMX guest mode Date: Tue, 21 Mar 2017 09:47:41 +0800 Message-ID: <58D0863D.4080001@huawei.com> References: <58C64672.1070706@huawei.com> <20170315173254.GF14081@potion> <58C9F3A5.3090604@huawei.com> <20170316142340.GD14076@potion> <58CB727B.20902@huawei.com> <20170320151815.GA25540@potion> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: kvm , Wanpeng Li , Gonglei To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= Return-path: Received: from szxga02-in.huawei.com ([45.249.212.188]:4345 "EHLO dggrg02-dlp.huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1754594AbdCUBsa (ORCPT ); Mon, 20 Mar 2017 21:48:30 -0400 In-Reply-To: <20170320151815.GA25540@potion> Sender: kvm-owner@vger.kernel.org List-ID: Hi Radim, On 2017/3/20 23:18, Radim Krčmář wrote: > 2017-03-17 13:22+0800, Longpeng (Mike): >> Hi Radim, ... >> In my humble opinion: >> >> 1) As "Intel sdm vol3 ch25.3" says, MWAIT operates normally (I think includes >> entering deeper sleep) under certain conditions. >> Some deeper sleep modes(such as C4E/C6/C7) will clear the L1/L2/L3 cache. >> This is insecurity if we don't take other protective measures(such as limit the >> guest's max-cstate, it's fortunately that power subsystem isn't supported by >> QEMU, but we should be careful for some special-purpose in case). While HLT in >> guest mode can't cause hardware into sleep. > > Good point. I'm not aware of any VMX capabilities to prevent deeper > C-states, so we'd always hope that guests obey provided information. > I'll do some tests this weekend. I plan to use MWAIT to enter deeper C-states in a testcase of kvm-unit-tests, and start a memory-sensitive workload on another hyper-thread, then use intel-pcm or perf to observe the count of cache miss on that core. >> 2) According to the "Intel sdm vol3 ch26.3.3 & ch27.5.6", I think MONITOR in >> guest mode can't work as perfect as in host sometimes. >> For example, a vcpu MONITOR a address and then MWAIT, if a external-intr(suppose >> this intr won't cause to inject any virtual events ) cause VMEXIT, the monitor >> address will be cleaned, so the MWAIT won't be waken up by a store operation to >> the monitored address any more. > > It's not as perfect, but should not cause a bug (well, there is a > discussion with suspicious MWAIT behavior :]). > MWAIT on all Intels I tested would just behave as a nop if exit happened > between MONITOR and MWAIT, like it does if you skip the MONITOR (MWAIT > instruction desciption): > > If the preceding MONITOR instruction did not successfully arm an > address range or if the MONITOR instruction has not been executed > prior to executing MWAIT, then the processor will not enter the > implementation-dependent-optimized state. Execution will resume at the > instruction following the MWAIT. > OK. :) >> But I'm glad to do some tests if time permits, thanks :) >> >> 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. > I had did some offline discussion with Wanpeng Li, he's interesting to write a path for this feature. :) > Thanks. > > . > -- Regards, Longpeng(Mike)