Re: [Question] About the behavior of HLT in VMX guest mode

["Longpeng (Mike)" <longpeng2@huawei.com>]

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)