public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Fiona Ebner <f.ebner@proxmox.com>
To: Christian Ludwig <christian_ludwig@genua.de>,
	pve-devel@lists.proxmox.com
Subject: Re: [PATCH v2 0/16] Support for custom EFI firmware
Date: Mon, 5 Oct 2026 16:36:15 +0200	[thread overview]
Message-ID: <a753e41d-bfb7-4a3b-9935-380a1e389c54@proxmox.com> (raw)
In-Reply-To: <cover.1790337423.git@genua.de>

Hi Christian,

Am 28.09.26 um 7:48 AM schrieb Christian Ludwig:
> Hi,
> 
> here is an updated patch series that brings support for custom UEFI
> firmware images. You can find the v1 series at [1] for reference.
> 
> In Confidential Computing the aim is to not trust the hypervisor, yet it
> runs its bundled firmware in each VM. Some VM appliances also ship their
> own firmware images. This series allows to bring your own firmware for
> OVMF based VMs.
> 
> Today the Proxmox-VE API allows to import a custom efidisk0 (EFIVAR)
> already. EFI firmware and EFIVAR data have to match. Otherwise, the VM
> might not boot anymore. Therefore, with this series you can set a custom
> EFI firmware via the API, along with a custom efidisk. But these are two
> steps. And there is no safety net. The GUI is missing a way to set a
> custom EFIVAR. So this series only allows to set a custom firmware image
> for confidential computing VMs that do not need EFIVAR storage. The
> defaults do not change.
> 

Looks mostly good to me (haven't looked at UI/docs yet). Apart from
comments on the individual patches, I do have two design
questions/considerations:

Format Extensions
=================

Would it be an issue to require/restrict file extensions here, i.e. only
allow names ending with '.fd', '.raw' and '.img' or similar?

1. It would protect against potential confusion, e.g. otherwise, there
can be a filename ending in '.qcow2'. While the code will look at the
returned format which is hard-coded/enforced to be 'raw', such a name
would still be confusing.

2. It would also allow us to extend support to non-raw formats in the
future. For example, we probably want to support IGVM [0] files as well
at some point. Have you already looked at that this format and what do
you think about it regarding your use case?

[0]: https://www.qemu.org/docs/master/system/igvm.html

'bios' as property string
=========================

I wonder if we should turn 'bios' into a property string with the
firmware file as a sub-property? This would couple the properties more
tightly.

===

Happy to hear opinions about these from you and also other developers!

Best Regards,
Fiona




  parent reply	other threads:[~2026-10-05 14:36 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-28  5:47 [PATCH v2 0/16] Support for custom EFI firmware Christian Ludwig
2026-09-28  5:47 ` [PATCH v2 pve-storage 1/16] plugin: add efi-firmware content type Christian Ludwig
2026-10-05 14:37   ` Fiona Ebner
2026-09-28  5:47 ` [PATCH v2 pve-storage 2/16] test: get_subdir: cover the " Christian Ludwig
2026-10-05 14:36   ` Fiona Ebner
2026-09-28  5:48 ` [PATCH v2 pve-storage 3/16] plugins: allow the efi-firmware content type on file based storages Christian Ludwig
2026-10-05 14:36   ` Fiona Ebner
2026-09-28  5:48 ` [PATCH v2 pve-storage 4/16] api: status: support efi-firmware in upload and download-url Christian Ludwig
2026-10-05 14:37   ` Fiona Ebner
2026-09-28  5:48 ` [PATCH v2 pve-storage 5/16] test: volume access: cover efi-firmware volumes Christian Ludwig
2026-10-05 14:36   ` Fiona Ebner
2026-09-28  5:48 ` [PATCH v2 pve-storage 6/16] test: list volumes: " Christian Ludwig
2026-10-05 14:37   ` Fiona Ebner
2026-09-28  5:48 ` [PATCH v2 qemu-server 07/16] config: add the efi-firmware option Christian Ludwig
2026-10-05 14:37   ` Fiona Ebner
2026-09-28  5:48 ` [PATCH v2 qemu-server 08/16] api: allow setting " Christian Ludwig
2026-10-05 14:36   ` Fiona Ebner
2026-09-28  5:48 ` [PATCH v2 qemu-server 09/16] ovmf: use a custom firmware image if configured Christian Ludwig
2026-10-05 14:36   ` Fiona Ebner
2026-09-28  5:48 ` [PATCH v2 qemu-server 10/16] test: efi-firmware key in VM config Christian Ludwig
2026-09-28  5:48 ` [PATCH v2 qemu-server 11/16] test: efi-firmware volumes replication Christian Ludwig
2026-09-28  5:48 ` [PATCH v2 pve-manager 12/16] ui: storage: add efi-firmware content type support Christian Ludwig
2026-09-28  5:48 ` [PATCH v2 pve-manager 13/16] ui: form: support other content types in the ISO selector Christian Ludwig
2026-09-28  5:48 ` [PATCH v2 pve-manager 14/16] ui: qemu: allow selecting a custom EFI firmware image Christian Ludwig
2026-09-28  5:48 ` [PATCH v2 pve-docs 15/16] pvesm: document the efi-firmware content type Christian Ludwig
2026-09-28  5:48 ` [PATCH v2 pve-docs 16/16] qm: document the efi-firmware VM option Christian Ludwig
2026-10-05 14:36 ` Fiona Ebner [this message]
2026-10-08  8:37   ` [PATCH v2 0/16] Support for custom EFI firmware Christian Ludwig

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=a753e41d-bfb7-4a3b-9935-380a1e389c54@proxmox.com \
    --to=f.ebner@proxmox.com \
    --cc=christian_ludwig@genua.de \
    --cc=pve-devel@lists.proxmox.com \
    /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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal