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)
