linux-kernel - Re: [RFC PATCH] KVM: x86: hyper-v: Inhibit APICv with VP Assist on SPR/EMR

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: <ZrJJPwX-1YjichNB@google.com>
Date: Tue, 6 Aug 2024 09:03:11 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Eiichi Tsukata <eiichi.tsukata@...anix.com>
Cc: chao.gao@...el.com, pbonzini@...hat.com, tglx@...utronix.de, 
	mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com, x86@...nel.org, 
	hpa@...or.com, vkuznets@...hat.com, kvm@...r.kernel.org, 
	linux-kernel@...r.kernel.org, jon@...anix.com
Subject: Re: [RFC PATCH] KVM: x86: hyper-v: Inhibit APICv with VP Assist on SPR/EMR

On Tue, Aug 06, 2024, Eiichi Tsukata wrote:
> Running multiple Windows VMs with VP Assis and APICv causes KVM internal
> error on Spapphire Rpaids and Emerald Rapids as is reported in [1].
> Here Qemu outputs:
> 
>   KVM internal error. Suberror: 3
>   extra data[0]: 0x000000008000002f
>   extra data[1]: 0x0000000000000020
>   extra data[2]: 0x0000000000000582
>   extra data[3]: 0x0000000000000006
>   RAX=0000000000000000 RBX=0000000000000000 RCX=0000000040000070
>   RDX=0000000000000000
>   RSI=fffffa8001e3db60 RDI=fffffa8002bc8aa0 RBP=fffff88005a91670
>   RSP=fffff88005a915c8
>   R8 =0000000000000009 R9 =000000000000000b R10=fffff8000264b000
>   R11=fffff88005a91750
>   R12=fffff88002e40180 R13=fffffa8001e3dc68 R14=fffffa8001e3dc68
>   R15=0000000000000002
>   RIP=fffff8000271722c RFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
>   ES =002b 0000000000000000 ffffffff 00c0f300 DPL=3 DS   [-WA]
>   CS =0010 0000000000000000 00000000 00209b00 DPL=0 CS64 [-RA]
>   SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS   [-WA]
>   DS =002b 0000000000000000 ffffffff 00c0f300 DPL=3 DS   [-WA]
>   FS =0053 00000000fff9a000 00007c00 0040f300 DPL=3 DS   [-WA]
>   GS =002b fffff88002e40000 ffffffff 00c0f300 DPL=3 DS   [-WA]
>   LDT=0000 0000000000000000 ffffffff 00c00000
>   TR =0040 fffff88002e44ec0 00000067 00008b00 DPL=0 TSS64-busy
>   GDT=     fffff88002e4b4c0 0000007f
>   IDT=     fffff88002e4b540 00000fff
>   CR0=80050031 CR2=00000000002e408e CR3=000000001c6f5000 CR4=000406f8
>   DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000
>   DR3=0000000000000000
>   DR6=00000000fffe07f0 DR7=0000000000000400
>   EFER=0000000000000d01
>   Code=25 a8 4b 00 00 b9 70 00 00 40 0f ba 32 00 72 06 33 c0 8b d0 <0f> 30
>   5a 58 59 c3 90 90 90 90 90 90 90 90 90 90 90 90 90 90 cc cc cc cc cc cc
>   66 66 0f 1f
> 
> As is noted in [1], this issue is considered to be a microcode issue
> specific to SPR/EMR.

I don't think we can claim that without a more explicit statement from Intel.
And I would really like Intel to clarify exactly what is going on, so that (a)
it can be properly documented and (b) we can implement a precise, targeted
workaround in KVM.

Chao?

> Disable APICv when guest tries to enable VP Assist page only when it's
> running on those problematic CPU models.
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=218267 [1]
> Signed-off-by: Eiichi Tsukata <eiichi.tsukata@...anix.com>
> ---