[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH 0/3] hw/pflash_cfi01: Reduce memory consumption when flas

From: David Edmondson
Subject: Re: [RFC PATCH 0/3] hw/pflash_cfi01: Reduce memory consumption when flash image is smaller than region
Date: Thu, 18 Feb 2021 10:34:19 +0000

On Tuesday, 2021-02-16 at 15:53:48 GMT, David Edmondson wrote:

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

Looking at the AAVMF implementation, it seems to me that if the initial
VARS image is prepared as being 768KiB in size (which it is), none of
AAVMF itself will attempt to write outside of that extent.

If that is correct, it would support the idea of allowing writes only to
the sub-region of the 64MiB that is covered by the backing block device.

This would allow the same approach as used for read-only devices to be
used for read-write devices - it's mostly a matter of deleting some code
from the patch that I sent. The additional patch on top of the previous
series would be:
(Presumably this would just be squashed into the previous patch in

If AAVMF is not going to try to use any of the region outside of the
VARS, do we need to persist writes to the rest of the region?

If so, would it be acceptable for those writes to persist only for the
lifetime of a QEMU instance? (Memory could be allocated "on demand" so
that a read after write would behave, but the content would be thrown
away when QEMU exits.)

Everyone I know, goes away in the end.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]