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]
Message-ID: <32d54ba8-9b12-2b8e-0b0d-052b75ba1db0@suse.de>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ