From: "Jörg Rödel" <joro@8bytes.org>
To: coconut-svsm@lists.linux.dev, linux-coco@lists.linux.dev
Subject: SVSM: Updated Linux and QEMU branches available for testing
Date: Thu, 27 Aug 2026 18:17:08 +0200 [thread overview]
Message-ID: <apBelv6Ev-lCQ64J@8bytes.org> (raw)
Hi,
I just pushed out new branches for COCONUT-SVSMs downstream Linux and QEMU
changes. The new branches need to be used together, as there have been rebases
which changed parts of the user-space interface. For Linux the branch is:
https://github.com/coconut-svsm/linux/tree/svsm-v7.2
For QEMU:
https://github.com/coconut-svsm/qemu/tree/svsm-v7.2
These new branches bring a set of changes and new features:
- KVM planes patches rebased to v7.2
- QEMU patches rewritten on v11.1.0
- Support for KVM planes with in-kernel IOAPIC/PIC/PIT/RTC
- Support for PCI device assignment with KVM planes
- Use of version 2 of the direct-VMSA patch-set
The last point deserves closer attention, as it will lead to a breaking change
going forward. The new version of the direct-VMSA patch-set requires a valid
VMSA GPA to be passed to KVM. The currently used GPA (0xFFFF_FFFF_F000) is NOT
a valid GPA.
For now QEMU will fall back to legacy behavior when it finds an invalid GPA in
the IGVM file, so everything keeps booting as ususal, except that the launch
measurement will not match anymore.
This can be easily fixed in the SVSM and I have a draft-PR open for that:
https://github.com/coconut-svsm/svsm/pull/1209
This PR moves the VMSA page into guest memory for QEMU, just like it is on
Hyper-V. The problem with that PR is that is breaks all existing Linux/QEMU
combinations, as they all have strict checks for the VMSA GPA to be a
0xFFFF_FFFF_F000.
My plan forward here is to switch to the new 7.2-based branches after everyone
had enough time to test them. After switching there will be even more time for
everyone else to switch over to the new downstream code. And only after that we
will merge PR #1209.
This is not an ideal situation and I'd like to have avoided more breaking
changes. But in this case I believe it is justified as avoiding this needs ugly
changes in the KVM direct-vmsa patch-set.
With that in mind I wish everyone happy testing. Please report any issues you
might find so that they can be fixed.
Regards,
Joerg
next reply other threads:[~2026-08-27 16:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-27 16:17 Jörg Rödel [this message]
2026-08-31 8:41 ` SVSM: Updated Linux and QEMU branches available for testing Liam Merwick
2026-08-31 15:24 ` Jörg Rödel
2026-09-01 0:58 ` Liam Merwick
2026-09-01 6:48 ` Jörg Rödel
2026-09-01 7:07 ` Jörg Rödel
2026-09-01 23:00 ` Liam Merwick
2026-09-02 9:18 ` Jörg Rödel
2026-09-02 13:54 ` Liam Merwick
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=apBelv6Ev-lCQ64J@8bytes.org \
--to=joro@8bytes.org \
--cc=coconut-svsm@lists.linux.dev \
--cc=linux-coco@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox