Re: [Qemu-devel] [RFC PATCH] hw/arm/virt: use variable size of flash device to save memory

[Markus Armbruster]

Zheng Xiang <address@hidden> writes:

> Hi Peter,
>
> Thanks for your reply!
>
> On 2019/3/25 21:11, Peter Maydell wrote:
>> On Mon, 25 Mar 2019 at 12:53, Xiang Zheng <address@hidden> wrote:
>>>
>>> Currently we fill the VIRT_FLASH space with two 64MB NOR images when
>>> using persistent UEFI variables on QEMU. Actually we only use a very
>>> small part of the memory while the rest significant large part of
>>> memory is wasted.
>>>
>>> This patch creates and maps a variable size of flash device instead of
>>> a mandatory 64MB one to save memory.
>>>
>>> Signed-off-by: Xiang Zheng <address@hidden>
>>> ---
>>>
>>> This patch might be insufficient since it also needs to modify the flash 
>>> size
>>> in ACPI and DTB.
>>>
>>> BTW, I don't understand why it requires the two NOR images to be exactly 
>>> 64MB
>>> in size when using -pflash.
>> 
>> I don't think we should do this. The board should in general
>> create the same hardware visible to the guest, not change
>> it based on subtle things like the size of the image files.

Concur.

>> The reason why the flash images must be 64MB in size
>> when using -pflash is that they are the backing store
>> for a writable device. Suppose you have 1MB of data in your
>> backing image that you pass to QEMU and then the guest writes
>> to the last block of the flash device. The new data
>> written by the guest to the end of the device has to be
>> stored somewhere, so the file has to be large enough
>> to cover the whole of the flash area.
>> 
>
> Is there any way to support config or limit the size that both
> guest and QEMU are visible?
>
> The original QEMU_EFI.fd has only 2M, but we need to stuff it
> to 64M with 62M unused data. It will consume a large amount of
> memory when running multiple VM simultaneously.

Here's a number of ideas.

The first one is of course making the flash memory size configurable, to
eliminate the "unused" part.  Our PC machines use the backing image
sizes as configuration.  I consider that a bad idea that should not be
allowed to spread to other machines.  Peter seems to agree.

The accepted way to create minor variations of a machine type is machine
properties.  Whether using them to vary flash chip size would be
acceptable is for the board maintainer to decide.

Now let's think about mapping these flash images more efficiently.

We could avoid backing their "unused" part with pages.  Unless the
"unused" part is read-only, this leaves you at your guests' mercy: they
can make the host allocate pages by writing to them.

We could share the pflash memory among VMs running the same firmware.
If writes are permitted, we'd have to unshare on write (COW).  Again,
you're at your guests' mercy unless read-only: they can make the host
unshare pages by writing to them.

I figure the "share" idea would be easier to implement[*].

Both ideas require either trusted guests or read-only flash.  EFI
generally wants some read/write flash for its var store.  Can we make
everything else read-only?

We can improve the device models to let us set up a suitable part of the
pflash memory read-only.  This is how real hardware works.  Our PC
machines currently approximate this with *two* flash chips, one
read-only, one read/write, which I consider a mistake that should not be
allowed to spread to other machines.

Prior discussions

    Message-ID: <address@hidden>
    https://lists.nongnu.org/archive/html/qemu-devel/2019-02/msg05056.html

and

    Message-ID: <address@hidden>
    https://lists.nongnu.org/archive/html/qemu-devel/2019-01/msg06606.html



[*] If you run KSM (kernel same-page merging), the kernel should set up
the sharing for you automatically.  But not everybody wants to run KSM.