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 for Android: free password hash cracker in your pocket

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

Message-ID: <ZrMNVYmqpDKulDdE@chao-email>
Date: Wed, 7 Aug 2024 13:59:49 +0800
From: Chao Gao <chao.gao@...el.com>
To: Sean Christopherson <seanjc@...gle.com>
CC: Eiichi Tsukata <eiichi.tsukata@...anix.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 at 09:03:11AM -0700, Sean Christopherson wrote:
>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?

I am asking if there is anything I can disclose at this point, including the
plan to disclose details of this issue and release the microcode fix.