Re: [Qemu-devel] [RFC] Writeable files in fw_cfg

[Jordan Justen]

On Sun, Jan 27, 2013 at 8:38 AM, David Woodhouse <address@hidden> wrote:
> On Sun, 2013-01-27 at 16:02 +0000, Blue Swirl wrote:
>> On Sun, Jan 27, 2013 at 3:50 PM, David Woodhouse <address@hidden> wrote:
>> > On Sun, 2013-01-27 at 15:14 +0000, Blue Swirl wrote:
>> >> It looks like this duplicates rom_add_file() and fw_cfg_add_file(), so
>> >> I don't see the point.
>> >
>> > Both of those are read-only, surely? The firmware inside the guest can't
>> > use them for non-volatile storage.
>>
>> Right. But why do we need PV non-volatile storage, instead of normal flash?
>
> People have looked at adding normal flash to the PC target,

FWIW, I do have non-volatile variables working for OVMF using
http://wiki.qemu.org/Features/PC_System_Flash

> but it has a
> number of problems. Firstly, it doesn't even *work* with KVM enabled.

Avi tells me KVM_MEM_READONLY may be a big step in solving this. But,
I'll admit that I've not made much progress on this part of the task.

> But even if we were to somehow fix that, the simple approach of
> emulating a BIOS flash is also very suboptimal; it puts the whole of the
> firmware *into* the flash and lets it store its non-volatile variables
> in the same emulated flash chip. So if you want to update the firmware
> (which would normally be just a case of updating the bios.bin file), you
> end up having to do each guest system individually *and* the update is
> painful because you have to preserve the non-volatile storage while
> updating the other parts.

It is a good point, and I originally thought of keeping them separate,
but it seems like we ended up heading down the PC System Flash path.

I think at one point being able to keep the firmware image static when
QEMU updated might have been seen as an advantage. Based on several
years experience, I think OVMF builds have continued to work well with
older and newer versions of QEMU.

Yet, for the user that just wants to have the latest firmware, well we
all probably know how much fun bios upgrades can be. :)

Anyway, I think OVMF probably will end up supporting PC System Flash
for non-volatile variables in addition to what ever comes of this
discussion.

> It's much better to have a separate storage for the non-volatile
> variables. Yes, we *could* teach it to use a dedicated flash chip for
> that rather than using flash for the firmware *and* storage as we would
> on real hardware. But if we're going to do something different for the
> virtualised case, a writeable fw_cfg file seems a whole lot easier and
> saner.

I just wish fw_cfg had a more flash-friendly interface. The EDK II
variable storage prefers random access to the non-volatile storage
bytes. The infrastructure generally is built around random writes and
block erases.

-Jordan