On Mon, Jan 31, 2022 at 03:35:02PM +0000, Daniel P. Berrangé wrote: > On Mon, Jan 31, 2022 at 04:21:36PM +0100, Kashyap Chamarthy wrote: > > On Mon, Jan 31, 2022 at 02:36:46PM +0000, Daniel P. Berrangé wrote: [...] > > > The firmware can be provided in qcow2 format too, so if really > > > concerned, just create a qcow2 file with a backing store pointing > > > to the readonly master, so you're only paying the price of the > > > delta for any guest VARs writes. That's more efficient than what > > > we do today with copying the separate raw format VARS.fd file. > > > > That's nice, I didn't know the qcow2 possibility in this context. For > > some reason I assumed the file format always has to be raw here. Your > > qcow2 point above should be documented, if it isn't already. Although > > I don't know the right place for it. > > There's already a format field in the descriptor, but even if the > firmware is distributed as raw, libvirt can choose to put qcow2 > overlay on it, as its all configured with -blockdev Ah, understood. I should've first checked the spec to look for the @format field. For others reading the thread, the @format bit is located here infirmware.json: [...] # @FirmwareFlashFile: # # Defines common properties that are necessary for loading a firmware # file into a pflash chip. The corresponding QEMU command line option is # "-drive file=@filename,format=@format". Note however that the # option-argument shown here is incomplete; it is completed under # @FirmwareMappingFlash. # # @filename: Specifies the filename on the host filesystem where the # firmware file can be found. # # @format: Specifies the block format of the file pointed-to by # @filename, such as @raw or @qcow2. [...] -- /kashyap
