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