On 02/24/15 20:43, Gabriel L. Somlo wrote: > Following up on a conversation I started a few weeks ago, regarding the > ability to pass "environment variables" into a guest from the host, via > the qemu command line, and without further requirements for guest- or > host-initiated synchronization at a later time, after the act of firing > up the guest. > > I remember we had discussed SMBIOS as one of the options for "transport" > of environment data; but then I thought that's still not "out-of-band" > enough for my taste. Seeing how SMBIOS is passed in via fw_cfg, I thought > the latter would be the perfect OOB transport mechanism for this type of > data. Except instead of being consumed by the BIOS on the booting guest, > the actual guest OS can read the data from fw_cfg directly. > > So, I added a -guestenv qemu command line option on the host side (1/2) > which results in the creation of a fw_cfg blob named "etc/guestenv", > and added --getenv to qga on the guest side (2/2), to query fw_cfg and > return the value of such an environment variable, if available. > > Right now it's only used with i386, but there's no reason why it couldn't > work with any guest type that uses fw_cfg. > > Currently it's pretty bare bones (e.g. I'm not checking for duplicate keys > on the host side, in fact I'm not even checking whether there's an '=' > character present in each -guestenv argument). I just wanted to get something > out there for folks to look at, and get feedback on whether this might be > of interest. > > The most important aspect of this feature is its asynchronous nature, i.e. > we can pass data into the guest without having to bring up a subsequent > connection (host->guest or guest-host) at a later time, with all the > failure-mode handling and coordination that would entail. > > A couple of extra random thoughts: > > On the host side, it might be interesting/useful to allow a random file > to be inserted into fw_cfg with a given fw_cfg name (something like > "-fwcfgblob name=foo,file=./bar"), where ./bar could be anything, even > a shell script or a text file with key=value pairs :) > > On the guest side, I think it might be cool to write a device driver for > fw_cfg, something that would allow reading fw_cfg blobs via > /sys/firmware/fw_cfg/... I think just reading the fw_cfg data port as root > is more portable (userspace code shipping with qga vs. kernel device driver), > which is why I haven't started coding on this already :) Not to mention I > don't know where I'd start with the equivalent driver for Windows :) > > > Anyhow, please let me know what you all think, and how it could be made > more compelling to the qemu community at large. > > > Thanks, > --Gabriel > > Gabriel L. Somlo (2): > fw_cfg: Add -guestenv qemu command line option > qga: add --getenv option to get env. vars from fw_cfg > > hw/i386/pc.c | 4 ++ > include/sysemu/sysemu.h | 3 ++ > qemu-options.hx | 9 ++++ > qga/Makefile.objs | 1 + > qga/getenv.c | 140 > ++++++++++++++++++++++++++++++++++++++++++++++++ > qga/guest-agent-core.h | 2 + > qga/main.c | 7 ++- > vl.c | 14 +++++ > 8 files changed, 179 insertions(+), 1 deletion(-) > create mode 100644 qga/getenv.c >
Matt Fleming was thinking about something like this, I'm CC'ing him. Thanks Laszlo
