On Tuesday, 2021-02-16 at 16:44:58 +01, Philippe Mathieu-Daudé wrote: > On 2/16/21 4:22 PM, David Edmondson wrote: >> On Tuesday, 2021-02-16 at 16:03:05 +01, Philippe Mathieu-Daudé wrote: >> >>> I am not a block expert, but I wonder if something like this could >>> be used: >>> >>> - create a raw (parent) block image of 64MiB >>> >>> - add a raw (child) block with your 768kB of VARS file >>> >>> - add a null-co (child) block of 63Mib + 256kiB >>> >>> - pass the parent block to the pflash device >> >> I'm not clear how this would behave if there is a write to the device at >> (say) 1MiB. > > Discarded. > >> More philosophically, how should it behave? > > null-co: reads return zeroes, writes are discarded. > >> My expectation was that if the machine says that there is 64MiB of >> writable flash, we have to allow writes throughout the full 64MiB and >> (significantly) persist them to the backing block device. >> >> Just because the backing block device started out 768KiB big doesn't >> mean that we should not write to the remaining extent if that's what the >> VM attempts. >> >> Would the above approach achieve that? (It doesn't sound like it.) > > Well this was a simple suggestion if you know your guest won't access > anything beside these 768KiB (IIRC AAVMF "consumes" the flash devices > and doesn't expose them to the guest via ACPI/other).
If that's the case, mirroring the approach in the patch that I sent should work - we run the 768kiB as a subregion with IO/ROMD behaviour, fail or discard writes to the rest and read as zero. > If you are into memory optimization, this is worth considering. > Else it doesn't make sense. > > AAVMF is designed for virtual world. Is the virtual world interested in > doing firmware upgrade on the CODE flash? Unlikely, if you want to > upgrade AAVMF you'd do it on the host. Why not mount the CODE flash as > ROM? I suppose because AAVMF does CFI MMIO accesses to detect the flash, > but I wonder what is the point if this flash will be ever written... I don't expect that the CODE flash will ever be written by the guest, no (it's generally presented to the guest as read-only), and currently the VARS flash is also often presented read-only as well, but I don't think that is a situation that we can maintain given increasing use (DBX updates, for example). If it's acceptable to limit flash writes to the extent of the underlying block device then things are straightforward. It's not clear to me that this is the case. dme. -- She's got no name, but she is family.
