Philippe Mathieu-Daudé <phi...@redhat.com> writes:
> 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). IIRC the two questions that came up were: - what would reading memory not covered by a file look like (0's or something more like real HW, 7f?). - what happens when the guest writes beyond the bounds of a backing file? I'm guessing for these cloudy type applications no one cares about persistence of EFI variables? Maybe we just need a formulation for the second pflash which is explicit about writes being ephemeral while also being accepted? > > Regards, > > Phil. -- Alex Bennée
