On 11/16/20 2:48 PM, Markus Armbruster wrote: > Philippe Mathieu-Daudé <phi...@redhat.com> writes: > >> Hi David, >> >> On 11/16/20 11:42 AM, David Edmondson wrote: >>> Currently ARM UEFI images are typically built as 2MB/768kB flash >>> images for code and variables respectively. These images are both then >>> padded out to 64MB before being loaded by QEMU. >>> >>> Because the images are 64MB each, QEMU allocates 128MB of memory to >>> read them, and then proceeds to read all 128MB from disk (dirtying the >>> memory). Of this 128MB less than 3MB is useful - the rest is zero >>> padding. >> >> 2 years ago I commented the same problem, and suggested to access the >> underlying storage by "block", as this is a "block storage". >> >> Back then the response was "do not try to fix something that works". >> This is why we choose the big hammer "do not accept image size not >> matching device size" way. >> >> While your series seems to help, it only postpone the same >> implementation problem. If what you want is use the least memory >> required, I still believe accessing the device by block is the >> best approach. > > "Do not try to fix something that works" is hard to disagree with. > However, at least some users seem to disagree with "this works". Enough > to overcome the resistance to change?
Yeah, at least 3 big users so far: - Huawei https://www.mail-archive.com/qemu-devel@nongnu.org/msg607292.html - Tencent https://www.mail-archive.com/qemu-devel@nongnu.org/msg742066.html - Oracle (this series). Then Huawei tried the MicroVM approach: https://www.mail-archive.com/qemu-devel@nongnu.org/msg680103.html I simply wanted to save David time by remembering this other approach, since Peter already commented on David's one (see Huawei link). Regards, Phil.
