On Tue, Feb 25, 2025 at 10:51:08AM +0530, Ani Sinha wrote:
> On Mon, Feb 24, 2025 at 9:17 PM Gerd Hoffman <kra...@redhat.com> wrote:
> >
> > Works nicely for me. Test case:
> > https://kraxel.gitlab.io/uefi-tools-rs/seabios.efi
>
> yeah if I can't get my unit test working we can make this an
> integration test. or best case scenario, we can have both.
Do you have a branch with your unit test somewhere?
> > Also this adds five fw_cfg files. Given that the number of fw_cfg files
> > we can have is limited I'm not convinced this is the best idea to move
> > forward.
>
> Right, For implementation, I suggest we combine FILE_VMFWUPDATE_OBLOB
> and FILE_VMFWUPDATE_FWBLOB together and also make
> FILE_VMFWUPDATE_CONTROL part of the same structure. These are all
> writable by the guest so makes sense to have one fwcfg for it. We can
> have another read-only fwcfg for FILE_VMFWUPDATE_BIOS_SIZE and
> FILE_VMFWUPDATE_CAP.
I'd prefer to put everything into one file. Maybe except the opaque
blob page. A struct along the lines of:
struct vmfwupdate {
u64 capabilities; // 'cap' file
u64 firmware_size; // 'bios-size' file
u64 control; // disable bit etc.
u64 update_paddr; // 'fw-blob' file, paddr field
u64 update_size; // 'fw-blob' file, size field
}
On the host side you'll need two copies of the struct then: one where
the guest can read from and write to, and one shadow struct where the
actual values are stored. The write callback goes sanity-check the
guest-written data, takes everything which passes into the shadow
struct, finally goes copy back the shadow struct to the guest struct
so the guest can see what the host has accepted.
Part of the verification process can be that you already copy the
firmware to a host buffer. Best using dma_* functions, these return
errors in case something went wrong (say the paddr passed is not backed
by guest ram). Which gives you the chance to propagate those errors
back to the guest before it'll actually try to launch the updated
firmware via reset.
take care,
Gerd
