Hi,
> > Going ship the distro kernel as igvm image would work too. Will
> > simplify the measurement pre-calculation. Also there is no need to pass
> > around any parameters, everything (how the firmware finds the UKI etc)
> > can be arranged at igvm build time then. Disadvantage: This introduces
> > a completely new boot workflow. Will probably need a new set of cloud
> > images exclusively for the BYOF case.
>
> What does all this mean for the hypervisor interface ?
That means we'll go scratch the region list idea and depend on igvm
instead.
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.
'opaque' exists as before, even though I think it makes sense to also
specify the size for the opaque blob. This gives the guest a bit more
flexibility in how this is used, for example it could pass the complete
UKI as opaque blob.
take care,
Gerd
------------------------------ cut here -----------------------------
struct vmfwupdate {
// VMM capabilities, see VMFWUPDATE_CAP_*, read-only.
uint64_t capabilities;
// control bits, see VMFWUPDATE_CTL_*
uint64_t control;
// firmware rom/flash storage size, read-only.
uint64_t fw_rom_size;
// 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;
// address + size of opaque blob. The guest can use this to pass on
// information, for example which memory region the linux kernel has been
// loaded to. writable, will be kept intact on firmware update.
uint64_t opaque_addr;
uint64_t opaque_size;
};
// --- format bits, used by both 'capabilities' and 'control' ---
// igvm
#define VMFWUPDATE_FORMAT_IGVM (1 << 32)
// rom/flash on platform-specific location
// - x86: below 4G + 1G
// - arm: 0
#define VMFWUPDATE_FORMAT_PLATFORM_ROM (1 << 33)
// --- 'capabilities' field bits ---
// vmm supports resizing of x86 firmware memory
#define VMFWUPDATE_CAP_X86_RESIZE (1 << 0)
// --- 'control' field bits ---
// disable vmfwupdate interface
#define VMFWUPDATE_CTL_DISABLE (1 << 0)
