[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 0/5] ARM: reduce the memory consumed when mapping UEFI fl
Re: [RFC PATCH 0/5] ARM: reduce the memory consumed when mapping UEFI flash images
Thu, 19 Nov 2020 12:57:21 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0
+Ard & Leif for EDK2.
On 11/19/20 12:45 PM, Alex Bennée wrote:
> Philippe Mathieu-Daudé <firstname.lastname@example.org> writes:
>> On 11/16/20 2:48 PM, Markus Armbruster wrote:
>>> Philippe Mathieu-Daudé <email@example.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
>>>> 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
>> - Tencent
>> - Oracle
>> (this series).
>> Then Huawei tried the MicroVM approach:
>> 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
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.
- [RFC PATCH 4/5] hw/arm: Flash image mapping follows image size, (continued)
- [RFC PATCH 4/5] hw/arm: Flash image mapping follows image size, David Edmondson, 2020/11/16
- [RFC PATCH 5/5] hw/arm: Only minimise flash size on older machines, David Edmondson, 2020/11/16
- [RFC PATCH 3/5] hw/arm: Convert assertions about flash image size to error_report, David Edmondson, 2020/11/16
- [RFC PATCH 2/5] hw/block: Flash images can be smaller than the device, David Edmondson, 2020/11/16
- Re: [RFC PATCH 0/5] ARM: reduce the memory consumed when mapping UEFI flash images, Philippe Mathieu-Daudé, 2020/11/16