Re: [RFC PATCH 0/3] hw/pflash_cfi01: Reduce memory consumption when flash image is smaller than region

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

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 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...

Regards,

Phil.