RE: [EXTERNAL] Re: KVM planes branches

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.

> 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.

Anything we do in the short term will be a hack, so picking a hack that is simplest for KVM is probably going to be the most expedient approach.  The fact is that KVM has no visibility at all into the set of features selected by the guest VMSA because guest VMSAs are within the guest private address space.  The only thing KVM can learn about the guest VMSA is whatever feature flags are passed as part of the AP_CREATE GHCB call.  The SVSM can simply lie by including the debug swap flag in the features it passes as a part of this GHCB call.

Of course, this assumes that KVM/QEMU are willing to handle the "set DR" GHCB calls that will be issued by the lower VMPL even if debug swap is specified as a feature of the lower VMPL.  I'm guessing that KVM doesn't gate its support for DR writes based on the SEV features it thinks are present, but I can't say for sure.  If KVM essentially ignores that SEV feature bit outside of the cross-VMPL comparison, then lying in the AP_CREATE GHCB call is best.  If KVM observes that bit to control GHCB behavior, then I think we'll be forced to change KVM to exclude that bit in the cross-VMPL comparison.

-Jon

-----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