KVM Planes Branches

KVM Planes Branches

[Jörg Rödel]

Hi all,

Now that Linux 7.1 is out the door I rebased the KVM planes patches and
prepared the updates for our downstream Linux kernel and QEMU branches.

For now I pushed the updates to separate branches for everyone to do some final
testing. Later this week I will update the svsm (Linux) and svsm-igvm (QEMU)
branches which our documentation points to.

The code is here:

	Linux: https://github.com/coconut-svsm/linux/tree/svsm-v7.1

	QEMU: https://github.com/coconut-svsm/qemu/tree/svsm-igvm-linux-v7.1

Besides the KVM planes support these branches also include the patches to
support direct VMSA setting from the IGVM file, so if you run test-in-svsm with
these branches the launch measrement should be correct.

Note that there are slight changes to the QEMU command line required. The
-machine specification needs to additional properties:

	kernel-irqchip=split,device-plane=2

Without either QEMU will not initialize or the Linux guest will get stuck
during boot.

So please give the changes a final test and report any issues.

Thanks,

	Jörg

KVM planes branches

[Oliver Steffen]

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?

Any hints are very welcome!

Cheers,
 Oliver

-- 
Oliver Steffen (he/him) - Software Engineer, Virtualization
Red Hat GmbH <https://www.redhat.com/de/global/dach>,
Registered seat: Werner-von-Siemens-Ring 12, D-85630 Grasbrunn, Germany
Commercial register: Amtsgericht München/Munich, HRB 153243,
Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross

Re: KVM planes branches

[Carlos López]

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

Re: KVM planes branches

[Carlos López]

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?

I managed to track down the issue to an infinite loop within KVM. Please
try the following fix:

    https://github.com/coconut-svsm/linux/pull/19

In my environment this allows edk2 to make progress and reach the grub
menu. As mentioned in a previous email, you will need to revert
539624271cb8 ("sev: require the debug register virtualization feature")
temporarily in the SVSM.

Best,
Carlos

Re: KVM planes branches

[Oliver Steffen]

On Mon, Jan 19, 2026 at 12:22 PM Carlos López <clopez@suse.de> wrote:
>
> 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?
>
> I managed to track down the issue to an infinite loop within KVM. Please
> try the following fix:
>
>     https://github.com/coconut-svsm/linux/pull/19
>
> In my environment this allows edk2 to make progress and reach the grub
> menu. As mentioned in a previous email, you will need to revert
> 539624271cb8 ("sev: require the debug register virtualization feature")
> temporarily in the SVSM.

Finally got around to try your PR. I am able to boot a Fedora 43 guest
through grub
into Linux, but it then hangs early:

[...]
[    0.000000] Linux version 6.17.1-300.fc43.x86_64
(mockbuild@5381c258a4b3436489a448ea66bda8ce) (gcc (GCC) 15.2.1
20250924 (Red Hat 15.2.1-2), GNU ld version 2.45-1.fc43) #1 SMP
PREEMPT_DYNAMIC Mon Oct  6 15:37:21 UTC 2025
[    0.000000] Command line:
BOOT_IMAGE=(hd0,gpt3)/vmlinuz-6.17.1-300.fc43.x86_64 no_timer_check
console=tty1 console=ttyS0,115200n8 systemd.firstboot=off
root=UUID=55773572-92c8-4d7e-bafd-3f4943a2f380 rootflags=subvol=root
[...]
[    1.650687] printk: legacy console [tty1] enabled
[1.651019] printk: legacy console [ttyS0] enabled
[    2.039270] ACPI: Core revision 20250404
[    2.079399] clocksource: hpet: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 19112604467 ns
[    2.086852] APIC: Switch to symmetric I/O mode setup
[    2.088986] x2apic enabled
[    2.090394] APIC: Switched APIC routing to: physical x2apic
[    2.111585] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[    2.113704] clocksource: tsc-
<hangs>

I added in https://github.com/coconut-svsm/linux/pull/18, same result.
Any ideas on what else to try?

Thanks!
 Oliver
>
> Best,
> Carlos
>