[Top][All Lists]

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

Re: [Qemu-arm] [RFC PATCH] hw/arm/virt: use variable size of flash devic

From: Zheng Xiang
Subject: Re: [Qemu-arm] [RFC PATCH] hw/arm/virt: use variable size of flash device to save memory
Date: Mon, 25 Mar 2019 22:03:03 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:64.0) Gecko/20100101 Thunderbird/64.0

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



reply via email to

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