On Sun, Jan 27, 2013 at 4:47 PM, David Woodhouse <dw...@infradead.org> wrote: > On Sun, 2013-01-27 at 10:29 -0600, Anthony Liguori wrote: >> David Woodhouse <dw...@infradead.org> 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 >
