From: "Gabriel L. Somlo" <gsomlo@gmail.com>
To: qemu-devel@nongnu.org
Cc: mdroth@linux.vnet.ibm.com, lersek@redhat.com, rjones@redhat.com
Subject: [Qemu-devel] [RFC PATCH 0/2] host->guest environment variables via fw_cfg
Date: Tue, 24 Feb 2015 14:43:05 -0500 [thread overview]
Message-ID: <1424806987-24790-1-git-send-email-somlo@cmu.edu> (raw)
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
--
2.1.0
next reply other threads:[~2015-02-24 19:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-24 19:43 Gabriel L. Somlo [this message]
2015-02-24 19:43 ` [Qemu-devel] [RFC PATCH 1/2] fw_cfg: Add -guestenv qemu command line option Gabriel L. Somlo
2015-02-24 19:43 ` [Qemu-devel] [RFC PATCH 2/2] qga: add --getenv option to get env. vars from fw_cfg Gabriel L. Somlo
2015-02-25 9:09 ` Daniel P. Berrange
2015-02-24 23:07 ` [Qemu-devel] [RFC PATCH 0/2] host->guest environment variables via fw_cfg Laszlo Ersek
2015-02-25 22:40 ` Matt Fleming
2015-02-26 1:13 ` Gabriel L. Somlo
2015-02-26 9:45 ` Laszlo Ersek
2015-02-26 10:55 ` Matt Fleming
2015-02-26 11:13 ` Richard W.M. Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1424806987-24790-1-git-send-email-somlo@cmu.edu \
--to=gsomlo@gmail.com \
--cc=lersek@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=rjones@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).