> On 8 Apr 2025, at 1:41 PM, Gerd Hoffman <kra...@redhat.com> wrote:
>
> Hi,
>
>> Which means we are back to the single firmware image. I think it makes
>> sense to continue supporting classic rom images (which can also be
>> loaded via -bios). Any use case which needs more fine-grained control
>> must use igvm. We can use format bits in both capabilities and control
>> fields to indicate what the hypervisor supports and what has been
>> uploaded to the firmware image region. See interface header file draft
>> below.
>
> Updated draft.
Is everyone OK with this latest draft version of the interface? Can we assume
that this is more or less how the final hypervisor interface would look on
QEMU?
> Idea is to go all-in on IGVM and support IGVM only. We
> keep the format bit, but more to make things future-proof (have the
> option to support other formats should the need arise at some point in
> the future) and not because we plan to support multiple formats today.
>
> So we are down to this:
>
> --------------------------- cut here ------------------------
>
> /*
> * igvm only vmfwupdate interface rewrite
> */
>
> struct vmfwupdate {
> // VMM capabilities, see VMFWUPDATE_CAP_*, read-only.
> uint64_t capabilities;
> // control bits, see VMFWUPDATE_CTL_*
> uint64_t control;
>
> // address and size of the firmware update image. Will be cleared on
> // firmware update and reset.
> uint64_t fw_image_addr;
> uint16_t fw_image_size;
> };
>
> // --- format bits, used by both 'capabilities' and 'control' ---
> // igvm
> #define VMFWUPDATE_FORMAT_IGVM (1 << 32)
>
> // --- 'control' field bits ---
> // disable vmfwupdate interface
> #define VMFWUPDATE_CTL_DISABLE (1 << 0)
>
> --------------------------- cut here ------------------------
>
> All other details will be offloaded to IGVM. We will need some IGVM
> format updates for that:
>
> * Add a parameter to specify the location of the payload (i.e.
> the UKI, or some container format in case we want pass on more
> than just one efi binary).
> * Add a page types for db/dbx signature databases where we can
> store either the signing key or the authenticode hash of the
> payload.
>
> take care,
> Gerd
>
