On Tue, Feb 25, 2025 at 2:09 PM Gerd Hoffman <kra...@redhat.com> wrote: > > 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.
I think we decided early on that we would not want to do that - that is consume extra memory on the host side for boot components. right alex? 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 >
