Re: [EXTERNAL] Re: KVM planes branches

On 1/16/26 5:21 PM, Jon Lange wrote:
> Carlos wrote:
> 
>> This is due to 539624271cb8 ("sev: require the debug register virtualization feature")
>> in the SVSM, as the SEV features for the guest VMSA do not match those of the VMPL0
>> VMSA, and the current KVM planes implementation rejects it:
> 
> In the future, KVM is going to have to accept different features in lower VMPLs, or else it will be impossible to enable features like alternate injection or REFLECT_VC (since those features can never be enabled for VMPL 0).  The best direction will be to eliminate any assumptions about cross-VMPL feature consistency.

Looking at it again, restricted injection and alternate injection are
considered "guest-controlled" SEV features in the KVM planes
implementation, meaning that they are exempt from the check. Perhaps we
should extend this to include debug swap.

Best,
Carlos

> -----Original Message-----
> From: Carlos López <[email protected]> 
> Sent: Friday, January 16, 2026 6:05 AM
> To: Oliver Steffen <[email protected]>; [email protected]
> Cc: Joerg Roedel <[email protected]>; Stefano Garzarella <[email protected]>; Luigi Leonardi <[email protected]>
> Subject: [EXTERNAL] Re: KVM planes branches
> 
> Hi,
> 
> On 1/7/26 3:02 PM, Oliver Steffen wrote:
>> Hi everyone,
>> happy new year!
>>
>> I am curious about the state of the KVM planes effort and want to 
>> experiment with it a bit.
>> I tried out the KVM planes branches we have in our GitHub org.
>> I built Qemu and the host kernel from there and I am able to launch 
>> the current SVSM with that. QEMU just needed the patch for MADT-via-IGVM.
>> But the OVMF does not seem to start. All I see is
>>
>> ...
>> [SVSM] VTPM: TPM 2.0 Reference Implementation initialized [SVSM] [CPU 
>> 0] Virtual memory pages used: 0 * 4K, 0 * 2M [SVSM] VMSA PA: 
>> 0x8000f49000 [SVSM] Launching Firmware [init] COCONUT-SVSM init 
>> process starting [SVSM] Terminating task init, exit_code 0 [SVSM] 
>> Launching request-processing task on CPU 1 [SVSM] Launching 
>> request-processing task on CPU 2 [SVSM] Launching request-processing 
>> task on CPU 0 [SVSM] Launching request-processing task on CPU 3
>>
>> and then it seems to hang forever.
>> Is that expected? Do I need a specific commit of SVSM or EDK2?
> 
> FWIW, boot now fails a bit earlier:
> 
>     (...)
>     [SVSM] VMSA PA: 0x8000f46000
>     [SVSM] Launching Firmware
>     error: kvm run failed Invalid argument
>     EAX=00000000 EBX=00000000 ECX=00000000 EDX=00800f12
>     ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
>     EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
>     ES =0000 00000000 0000ffff 00009300
>     CS =f000 ffff0000 0000ffff 00009b00
>     SS =0000 00000000 0000ffff 00009300
>     DS =0000 00000000 0000ffff 00009300
>     FS =0000 00000000 0000ffff 00009300
>     GS =0000 00000000 0000ffff 00009300
>     LDT=0000 00000000 0000ffff 00008200
>     TR =0000 00000000 0000ffff 00008b00
>     GDT=     00000000 0000ffff
>     IDT=     00000000 0000ffff
>     CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
>     DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000
> DR3=0000000000000000
>     DR6=00000000ffff0ff0 DR7=0000000000000400
>     EFER=0000000000000000
>     Code=c5 5a 08 2d 00 00 00 00 00 00 00 00 00 00 00 00 56 54 46 00 <0f> 20 c0 a8 01 74 05 e9 0c ff ff ff e9 f1 fe 90 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00
>     qemu-system-x86_64: terminating on signal 2
> 
> This is due to 539624271cb8 ("sev: require the debug register virtualization feature") in the SVSM, as the SEV features for the guest VMSA do not match those of the VMPL0 VMSA, and the current KVM planes implementation rejects it:
> 
>     [251378.096570] [ T91528] kvm_amd: kvm [91524]: vcpu0, guest rIP:
> 0x0 vmgexit: mismatched AP sev_features [0x1] != [0x29] from guest
> 
> Not sure if the best approach is to special-case debug swap, or to simply allow lower VMPL VMSAs to have a subset of the features of the VMPL 0 VMSA.
> 
> Reverting the commit I mention above results again in the hang that Oliver reports.
> 
> Best,
> Carlos
>