public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Christian Ludwig <christian_ludwig@genua.de>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>,
	"f.ebner@proxmox.com" <f.ebner@proxmox.com>
Subject: Re: [PATCH v2 0/16] Support for custom EFI firmware
Date: Thu, 8 Oct 2026 08:37:13 +0000	[thread overview]
Message-ID: <bca3e4bf89dedfe9ad67a194d1f1ba0c734c94c5.camel@genua.de> (raw)
In-Reply-To: <a753e41d-bfb7-4a3b-9935-380a1e389c54@proxmox.com>

Hi,

thanks for taking the time to review the patchset.

On Mon, 2026-10-05 at 16:36 +0200, Fiona Ebner wrote:
> 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?

There is no issue with that. The OVMF build yields firmware files with
a '.fd' extension by default.

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

Agreed. I suggest we restrict it to '.fd' only. That extension is not
in use, yet. So there is no confusion.

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

We have not looked into IGVM in detail, yet. But it looks promising.
And it may well live next to OVMF files in efi-firmware storage. Both
formats fit the current design. Both file types are immutable and
shared across multiple VMs.

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

Sure. I'll give it a shot. The tight coupling of these properties has
led us to move the custom efi firmware option to the VM.Config.Options
permission in this patchset revision. We felt that moving the bios
option to VM.Config.HWType is a big breaking change and off the table.
 
> ===
> 
> Happy to hear opinions about these from you and also other
> developers!
> 
> Best Regards,
> Fiona

I'll consider your comments from patch reviews. No complaints there.
Will rework and send an update.


 - Christian

      reply	other threads:[~2026-10-08  8:37 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 ` [PATCH v2 0/16] Support for custom EFI firmware Fiona Ebner
2026-10-08  8:37   ` Christian Ludwig [this message]

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=bca3e4bf89dedfe9ad67a194d1f1ba0c734c94c5.camel@genua.de \
    --to=christian_ludwig@genua.de \
    --cc=f.ebner@proxmox.com \
    --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