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

[Blue Swirl]

On Sun, Jan 27, 2013 at 4:47 PM, David Woodhouse <address@hidden> wrote:
> On Sun, 2013-01-27 at 10:29 -0600, Anthony Liguori wrote:
>> David Woodhouse <address@hidden> writes:
>>
>> > For OVMF we really want to have a way to store non-volatile variables,
>> > other than the dirty hack that currently puts them on a file in the EFI
>> > system partition.
>> >
>> > It looks like we've supported writing to fw_cfg items fairly much since
>> > they were introduced, but we've never actually made use of that.
>> >
>> > This WIP patch kills the existing fw_cfg_add_callback() because I can't
>> > see how it would ever be useful, and it doesn't seem to have been used
>> > for years, if ever. And adds something slightly more useful.
>> >
>> > Other then the obvious bits that need finishing, any objections?
>>
>> The main issue is malicious guests.  The administrator has to be aware
>> of and in control of how much disk space the guest can use.  The
>> secondary issue is how to tie into the block layer so things like live
>> migration work.
>>
>> This is why "use a flash device" is an attractive answer here because it
>> gives a fixed sized storage pool that's configurable by the
>> administrator.
>
> That part is fixable simply by imposing a maximum size, surely?
>
>> Since it's backed by a block device, it supports all of
>> the features needed for non-volatile storage (snapshotting, live copy,
>> etc.).
>>
>> The only real downside is that it's opaque to the host.  If it's
>> desirable to have something that's visible to the host, then I think we
>> would still need to make use of BlockDriverState as the means to make it
>> non-volatile.
>
> I don't really care about it being visible to the host. The important
> thing is that it's easily usable from the guest firmware at runtime, and
> not on a device that the OS might be trying to use. Their current trick
> is a file on the EFI system partition, which is definitely *not*
> acceptable. It doesn't work after the OS has booted, so even basic tasks
> like "install an OS and hope the installer can set the boot variables to
> boot into it" are broken.
>
> For exposing it to the guest, writeable fw_cfg definitely seems like the
> most attractive answer. I'll look at backing it with BlockDriverState. I
> don't even think we need a file system on it; it can just be a
> fixed-size device exposed as-is, surely?

For example hw/spapr_nvram.c implements a similar device. If the user
does not specify any backing file for nvram, its contents will not be
saved.

>
> --
> dwmw2
>