Archive EDK2 fork

[stefano-garzarella]

Originally posted by @kraxel in #824 (comment)

My PR was just merged into master.

I'm wondering whenever the coconut edk2 fork should be archived to avoid confusion?
I think there is little reason to /not/ work against upstream tianocore repo, or do we have important svsm changes which are not merged upstream?
@stefano-garzarella

[stefano-garzarella]

@kraxel I'm moving the discussion here:

My PR was just merged into master.

Great!

I'm wondering whenever the coconut edk2 fork should be archived to avoid confusion? I think there is little reason to /not/ work against upstream tianocore repo, or do we have important svsm changes which are not merged upstream? @stefano-garzarella

I think so. @osteffenrh do you remember if we have anything else?

I'll bring this to the TSC meeting tomorrow and if no one will complain, I'll update our documentation (to point to upstream commit) and archive our fork like we did for https://github.com/coconut-svsm/ms-tpm-20-ref.

Not sure if we want to keep it for future development (e.g. reboot work, but in that case maybe it's just Linux to be modified). In that case we should just rebase svsm on current upstream master.

[luigix25]

FYI @RARelph patches are being reviewed in upstream edk2 (tianocore/edk2#11536)

OvmfPkg/X64: add opt/org.tianocore/UninstallMemAttrProtocol support is not really needed to boot a CVM.

So the only extra commit we have is OvmfPkg/AmdSevDxe: Shim Reboot workaround, not really sure about this, though.

[kraxel]

OvmfPkg/X64: add opt/org.tianocore/UninstallMemAttrProtocol support is not really needed to boot a CVM.

Also fixed grub versions which do not need that workaround are finding their way into distros.
debian 13, fedora 43, rhel-9.7, rhel-10.1 are all fine.

[osteffenrh]

Hm. I'd like to reach a state where we can completely rely on upstream edk2, but I have the feeling we will dig this repo out of the archive sooner or later (which is fine).

I am also somewhat "attached" to the shim workaround. I think normal distro images should just boot through, without the user having to take action. If we can find a way to do that without the patch I am happy :-)

debian 13, fedora 43, rhel-9.7, rhel-10.1 are all fine.

Are we ok with limiting the choice of distros in that way? What about the opensuse image that is mentioned in our documentation?

[kraxel]

Hm. I'd like to reach a state where we can completely rely on upstream edk2, but I have the feeling we will dig this repo out of the archive sooner or later (which is fine).

Archiving right away is probably not realistic, but working into that direction by getting the changes we depend on merged upstream, then archive after one of the upcoming stable tags (2025-11 or 2026-02) should be possible.

I am also somewhat "attached" to the shim workaround. I think normal distro images should just boot through, without the user having to take action. If we can find a way to do that without the patch I am happy :-)

tianocore/edk2#11565 + virt-fw-vars --inplace OVMF.amdsev.fd --set-fallback-no-reboot

debian 13, fedora 43, rhel-9.7, rhel-10.1 are all fine.

Are we ok with limiting the choice of distros in that way? What about the opensuse image that is mentioned in our documentation?

No idea what the opensuse status wrt grub bugs is, but their leap 16 release is just around the corner ...

[osteffenrh]

tianocore/edk2#11565 + virt-fw-vars --inplace OVMF.amdsev.fd --set-fallback-no-reboot

I tried that with an unmodified Fedora 43 cloud image as guest: Works. Awesome!
Fedora 42 does not boot, due to Grub bugs (as you mentioned).

I used this to build ovmf:

build \
  -t GCC \
  -p OvmfPkg/AmdSev/AmdSevX64.dsc \
  --pcd PcdFirmwareVersionString=Ledk2-amdsev-svsm-g${COMMIT}\\0 \
  -a X64 \
  -D TPM2_ENABLE=TRUE \
  -D TPM2_CONFIG_ENABLE=TRUE \
  -D TPM1_ENABLE=FALSE \
  -D FD_SIZE_4MB=TRUE \
  -D DEBUG_ON_SERIAL_PORT -D DEBUG_VERBOSE \
  -b DEBUG

virt-fw-vars \
  -i Build/AmdSev/DEBUG_GCC/FV/OVMF.fd \
  --set-fallback-no-reboot \
  -o ./OVMF-amdsev-svsm-g${COMMIT}.fd

[RARelph]

My (modified) patches are now merged in to the upstream EDK2/master branch. tianocore/edk2#11536<tianocore/edk2#11536> Richard On Sep 29, 2025, at 10:52 AM, Luigi Leonardi ***@***.***> wrote: Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. [https://avatars.githubusercontent.com/u/5408949?s=20&v=4]luigix25 left a comment (coconut-svsm/svsm#827)<#827 (comment)> FYI @RARelph<https://github.com/RARelph> patches are being reviewed in upstream edk2 (tianocore/edk2#11536<tianocore/edk2#11536>) OvmfPkg/X64: add opt/org.tianocore/UninstallMemAttrProtocol support<tianocore/edk2@2abf30d> is not really needed to boot a CVM. So the only extra commit we have is OvmfPkg/AmdSevDxe: Shim Reboot workaround<tianocore/edk2@f9a36ab>, not really sure about this, though. — Reply to this email directly, view it on GitHub<#827 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKRYGJXVUEFAXKMTOERNKKL3VFITHAVCNFSM6AAAAACHZQ7M3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNBXG44TENBYGY>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[luigix25]

great! I'll do a rebase when the next edk2 stable version comes out.
I am afraid that we'll still need tianocore/edk2@2abf30d, to boot all the OSs without the grub fix in place.