linux-kernel - Re: [PATCH] KVM: nVMX: fix MWAIT emulation for guests

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 4 May 2017 11:43:31 +0200
From:   Alexander Graf <agraf@...e.de>
To:     Wanpeng Li <kernellwp@...il.com>, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Wanpeng Li <wanpeng.li@...mail.com>,
        "Michael S . Tsirkin" <mst@...hat.com>,
        "Gabriel L. Somlo" <gsomlo@...il.com>
Subject: Re: [PATCH] KVM: nVMX: fix MWAIT emulation for guests



On 04.05.17 11:37, Wanpeng Li wrote:
> From: Wanpeng Li <wanpeng.li@...mail.com>
>
> The kvm-unit-tests/vmx.flat fails against instruction(mwait) intercept test.
>
> Test suite: instruction intercept
> Unhandled exception 13 #GP at ip 0000000000402397
> error_code=0000      rflags=00010012      cs=00000008
> rax=0000000000000000 rcx=0000000004006172 rdx=0000000000402397 rbx=000000000041427d
> rbp=0000000007ff8fdf rsi=0000000000000000 rdi=0000000000000004
>  r8=000000000000000a  r9=00000000000003f8 r10=0000000000000000 r11=0000000000000000
>  r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000
> cr0=0000000080010031 cr2=0000000000000000 cr3=0000000007fff000 cr4=0000000000002020
> cr8=0000000000000000
>  	STACK: @402397 401102 400459
>
> This testcase will run mwait instruction unconditional in L2 w/o check mwait
> cpuid. The vmlauch/vmresume emulation will merge L0's requirements and L1's
> requests, kvm-unit-tests doesn't set MWAIT/MONITOR EXITING bits for vmcs12.
> w/o commit 668fffa3f838 ("kvm: better MWAIT emulation for guests"), the
> MWAIT/MONITOR EXITING bits in vmcs02 will be set since it is set in vmcs01
> though not in vmcs12. However, w/ the commit the bits will not be set in vmcs02
> since the bits are both not set in vmcs01(if kvm_mwait_in_guest() returns true)
> and vmcs12.
>
> L2 should not occupy all the cpu time on L0 when L2 is idle, this patch fix it
> by unconditional set MWAIT/MONITOR EXTING bits against vmcs02.

I don't understand - why not? If both L0 and L1 hypervisors allow MWAIT 
execution, why should we stop L2 from executing it?

We don't prevent L2 from running busy loops either, right?


Alex