Re: [edk2] [PATCH v2 8/8] AArch64-KVM: add support for non-volatile variable store

Subject: Re: [edk2] [PATCH v2 8/8] AArch64-KVM: add support for non-volatile variable store

From: Laszlo Ersek <>

To: Peter Maydell <>, Ard Biesheuvel <>

Date: 2014-08-28 04:33:18

On 08/27/14 20:09, Peter Maydell wrote:
> On 27 August 2014 17:58, Ard Biesheuvel  wrote:
>> On 27 August 2014 18:03, Laszlo Ersek  wrote:
>>> - Why require a 64MB flash drive, if we only use 768 KB of it?
>> The ARM Versatile Express development hardware is set up like this,
>> that is the whole and only reason.
>> I guess we could change it if there is a strong reason to do so, but
>> parity with the other emulated machines makes the maintenance job a
>> bit easier, I imagine.
> Yeah, this isn't a strong requirement from the QEMU side, but
> the thought process went something like:
>  * two flash devices is better than one, so we can allow a split
>    between what kind of backing file they get (treating ROM
>    image differently than non-volatile storage)

ACK for that, positively

>  * might as well be reasonably generous with the sizing, to
>    allow for future expansion in what software uses
>  * having an asymmetric "one small, one large" setup seems
>    kind of weird
>  * UEFI isn't necessarily the only user of this board model

Okay. Thanks!

> If we've done something silly with the way we've instantiated
> the flash device in QEMU that means it has a stupid large
> block size then we might be able to fix that.

The old wisdom says "measure it first" :)

I think this should only matter on KVM, if it matters at all. And one
way to measure it (if someone really cares) would be to run a Linux
guest, and massage some non-volatile variables from there, in a loop.

An example program is under

However I think this investigation can be postponed indefinitely (unless
someone notices a perf degradation with the naked eye). The only thing
that caught my eye was the block size being *different* from OVMF's and
"hw/i386/pc_sysfw.c"'s, but that isn't necessarily a problem.

I think this patch is fine unless proven otherwise in practice.


Slashdot TV.  
Video for Nerds.  Stuff that matters.
edk2-devel mailing list