+Ard & Leif for EDK2. On 11/19/20 12:45 PM, Alex Bennée wrote: > 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?).
For NOR flashes erased bit is high, programmed bit is low, so: 0xff. > > - what happens when the guest writes beyond the bounds of a backing > file? Report an hardware error, so guest firmware have a chance to do do something (not sure what, beside rebooting...). > > 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? Someone suggested adding a new machine type to QEMU to be able to use smaller flash for cloud usage (but I don't remember who). Then EDK2 could be built with for this new flash size. Regards, Phil.
