[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH 0/2] host->guest environment variables via f
Re: [Qemu-devel] [RFC PATCH 0/2] host->guest environment variables via fw_cfg
Wed, 25 Feb 2015 00:07:37 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
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.
> 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.