Re: [Qemu-devel] [RFC PATCH 0/2] host->guest environment variables via fw_cfg

[Laszlo Ersek <lersek@redhat.com>]

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