[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] fw_cfg: insert string blobs via qemu cmdline
From: |
Laszlo Ersek |
Subject: |
Re: [Qemu-devel] [PATCH] fw_cfg: insert string blobs via qemu cmdline |
Date: |
Mon, 28 Sep 2015 15:30:28 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 |
On 09/27/15 00:55, Gabriel L. Somlo wrote:
> Allow users to provide custom fw_cfg blobs with ascii string
> payloads specified directly on the qemu command line.
>
> Suggested-by: Jordan Justen <address@hidden>
> Suggested-by: Laszlo Ersek <address@hidden>
> Signed-off-by: Gabriel Somlo <address@hidden>
> ---
> docs/specs/fw_cfg.txt | 5 +++++
> qemu-options.hx | 7 ++++++-
> vl.c | 30 ++++++++++++++++++++++++------
> 3 files changed, 35 insertions(+), 7 deletions(-)
>
> diff --git a/docs/specs/fw_cfg.txt b/docs/specs/fw_cfg.txt
> index b5f4b5d..4d85701 100644
> --- a/docs/specs/fw_cfg.txt
> +++ b/docs/specs/fw_cfg.txt
> @@ -236,6 +236,11 @@ the following syntax:
> where <item_name> is the fw_cfg item name, and <path> is the location
> on the host file system of a file containing the data to be inserted.
>
> +Small enough items may be provided directly as strings on the command
> +line, using the syntax:
> +
> + -fw_cfg [name=]<item_name>,content=<string>
> +
Please consider spelling out that these blobs will NOT be NUL-terminated
when viewed on the guest. (It kinda follows from all the other fw_cfg
things, but once we leave host-side files for qemu command line strings,
it might become non-obvious to users.)
So something like, "... the content presented to the guest will not be
NUL-terminated, same as if the string was written to a host-side file
first".
Please also stress that such content (and actually name too, but that's
more generic) should be plain ASCII; let's sidestep any tricks a shell's
locale settings could pull on us.
> NOTE: Users *SHOULD* choose item names beginning with the prefix "opt/"
> when using the "-fw_cfg" command line option, to avoid conflicting with
> item names used internally by QEMU. For instance:
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 328404c..0b6f5bd 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -2724,13 +2724,18 @@ ETEXI
>
> DEF("fw_cfg", HAS_ARG, QEMU_OPTION_fwcfg,
> "-fw_cfg [name=]<name>,file=<file>\n"
> - " add named fw_cfg entry from file\n",
> + " add named fw_cfg entry from file\n"
> + "-fw_cfg [name=]<name>,content=<str>\n"
> + " add named fw_cfg entry from string\n",
Looks good. I got worried for a second that spelling out -fw_cfg twice
is not consistent with the rest of the documentation, but there are many
other such examples (-smbios, -netdev, -net, -chardev etc).
> QEMU_ARCH_ALL)
> STEXI
> @item -fw_cfg address@hidden,address@hidden
> @findex -fw_cfg
> Add named fw_cfg entry from file. @var{name} determines the name of
> the entry in the fw_cfg file directory exposed to the guest.
> +
> address@hidden -fw_cfg address@hidden,address@hidden
> +Add named fw_cfg entry from string.
> ETEXI
>
> DEF("serial", HAS_ARG, QEMU_OPTION_serial, \
Looks good. I checked with -chardev, and indeed @findex stands only
after the first occurrence of the option.
> diff --git a/vl.c b/vl.c
> index e211f6a..7f35f40 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -512,6 +512,10 @@ static QemuOptsList qemu_fw_cfg_opts = {
> .type = QEMU_OPT_STRING,
> .help = "Sets the name of the file from which\n"
> "the fw_cfg blob will be loaded",
> + }, {
> + .name = "content",
> + .type = QEMU_OPT_STRING,
> + .help = "Sets the content of the fw_cfg blob to be inserted",
> },
> { /* end of list */ }
> },
> @@ -2236,7 +2240,7 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts,
> Error **errp)
> {
> gchar *buf;
> size_t size;
> - const char *name, *file;
> + const char *name, *file, *content;
>
> if (opaque == NULL) {
> error_report("fw_cfg device not available");
> @@ -2244,8 +2248,17 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts,
> Error **errp)
> }
> name = qemu_opt_get(opts, "name");
> file = qemu_opt_get(opts, "file");
> - if (name == NULL || *name == '\0' || file == NULL || *file == '\0') {
> - error_report("invalid argument value");
> + content = qemu_opt_get(opts, "content");
> +
> +#define HAVE_OPT(arg) ((arg) && (*arg))
Not sure if this is usual in QEMU, but if it is, please also #undef the
macro after you are done using it.
Also, I recommend renaming HAVE_OPT() to NONEMPTY_STR().
> +
> + /* we need name and either a file or the content string */
> + if (!(HAVE_OPT(name) && (HAVE_OPT(file) || HAVE_OPT(content)))) {
> + error_report("invalid argument(s)!");
Please drop the exclamation mark.
> + return -1;
> + }
> + if (HAVE_OPT(file) && HAVE_OPT(content)) {
> + error_report("file and content are mutually exclusive!");
Ditto.
> return -1;
> }
> if (strlen(name) > FW_CFG_MAX_FILE_PATH - 1) {
> @@ -2256,9 +2269,14 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts,
> Error **errp)
> error_report("WARNING: externally provided fw_cfg item names "
> "should be prefixed with \"opt/\"!");
> }
> - if (!g_file_get_contents(file, &buf, &size, NULL)) {
> - error_report("can't load %s", file);
> - return -1;
> + if (HAVE_OPT(content)) {
> + buf = g_strdup(content);
> + size = strlen(buf);
I wonder if we should really duplicate the content here. I think we
could get away with just linking the option string into fw_cfg.
But, for consistency with the other branch, I don't mind. :)
Also, strlen() is okay (it will not expose the terminating NUL to the
guest), but I think we shouldn't *allocate* / duplicate that NUL either.
g_strdup() does though.
How about calling strlen() first, and then replacing g_strdup() with
g_memdup()?
Not crazy important though.
> + } else {
> + if (!g_file_get_contents(file, &buf, &size, NULL)) {
> + error_report("can't load %s", file);
> + return -1;
> + }
> }
> fw_cfg_add_file((FWCfgState *)opaque, name, buf, size);
> return 0;
>
Just small nits; looks okay to me otherwise. Thank you for coding this
up (and thanks Jordan for the suggestion), because this way we can
insert "-fw_cfg name=opt/ovmf/PcdXXX,content=Y" in a libvirt domain XML
directly, using <qemu:arg>, without referencing external files.
Thanks!
Laszlo
- [Qemu-devel] [PATCH] fw_cfg: insert string blobs via qemu cmdline, Gabriel L. Somlo, 2015/09/26
- Re: [Qemu-devel] [PATCH] fw_cfg: insert string blobs via qemu cmdline,
Laszlo Ersek <=
- Re: [Qemu-devel] [PATCH] fw_cfg: insert string blobs via qemu cmdline, Gabriel L. Somlo, 2015/09/29
- Re: [Qemu-devel] [PATCH] fw_cfg: insert string blobs via qemu cmdline, Eric Blake, 2015/09/29
- Re: [Qemu-devel] [PATCH] fw_cfg: insert string blobs via qemu cmdline, Gabriel L. Somlo, 2015/09/29
- Re: [Qemu-devel] [PATCH] fw_cfg: insert string blobs via qemu cmdline, Eric Blake, 2015/09/29
- Re: [Qemu-devel] [PATCH] fw_cfg: insert string blobs via qemu cmdline, Laszlo Ersek, 2015/09/29
- Re: [Qemu-devel] [PATCH] fw_cfg: insert string blobs via qemu cmdline, Laszlo Ersek, 2015/09/29
- Re: [Qemu-devel] [PATCH] fw_cfg: insert string blobs via qemu cmdline, Gabriel L. Somlo, 2015/09/29
- Re: [Qemu-devel] [PATCH] fw_cfg: insert string blobs via qemu cmdline, Laszlo Ersek, 2015/09/29
- Re: [Qemu-devel] [PATCH] fw_cfg: insert string blobs via qemu cmdline, Gabriel L. Somlo, 2015/09/29