[libvirt] [PATCH v4 1/2] qemu: Allow UEFI paths to be specified at compile time
Martin Kletzander
mkletzan at redhat.com
Mon Jan 26 09:34:34 UTC 2015
On Wed, Jan 21, 2015 at 08:21:28PM +0100, Michal Privoznik wrote:
>Up until now there are just two ways how to specify UEFI paths to
>libvirt. The first one is editing qemu.conf, the other is editing
>qemu_conf.c and recompile which is not that fancy. So, new
>configure option is introduced: --with-loader-nvram which takes a
>list of pairs of UEFI firmware and NVRAM store. This way, the
>compiled in defaults can be passed during compile time without
>need to change the code itself.
>
>Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
>---
> configure.ac | 12 ++++++++++++
> src/qemu/qemu_conf.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++
> tests/domaincapstest.c | 15 ++++++++-------
> 3 files changed, 70 insertions(+), 7 deletions(-)
>
>diff --git a/configure.ac b/configure.ac
>index f370475..7153fa5 100644
>--- a/configure.ac
>+++ b/configure.ac
>@@ -2789,6 +2789,18 @@ AC_ARG_WITH([default-editor],
> [DEFAULT_EDITOR=vi])
> AC_DEFINE_UNQUOTED([DEFAULT_EDITOR], ["$DEFAULT_EDITOR"], [Default editor to use])
>
>+AC_ARG_WITH([loader-nvram],
>+ [AS_HELP_STRING([--with-loader-nvram],
>+ [Pass list of pairs of <loader>:<nvram> paths. Both
>+ pairs and list items are separated by a colon.
>+ @<:default=paths to OVMF and its clones@:>@])],
>+ [if test "$withval" = "no"; then
>+ withval=""
>+ fi
>+ AC_DEFINE_UNQUOTED([DEFAULT_LOADER_NVRAM],
>+ ["$withval"],
>+ [List of laoder:nvram pairs])])
>+
> # Some GNULIB base64 symbols clash with a kerberos library
> AC_DEFINE_UNQUOTED([isbase64],[libvirt_gl_isbase64],[Hack to avoid symbol clash])
> AC_DEFINE_UNQUOTED([base64_encode],[libvirt_gl_base64_encode],[Hack to avoid symbol clash])
>diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
>index a24c5c5..3e51b49 100644
>--- a/src/qemu/qemu_conf.c
>+++ b/src/qemu/qemu_conf.c
>@@ -107,6 +107,49 @@ void qemuDomainCmdlineDefFree(qemuDomainCmdlineDefPtr def)
> VIR_FREE(def);
> }
>
>+
>+static int ATTRIBUTE_UNUSED
>+virQEMUDriverConfigLoaderNVRAMParse(virQEMUDriverConfigPtr cfg,
>+ const char *list)
>+{
>+ int ret = -1;
>+ char **token;
>+ size_t i;
>+
>+ if (!(token = virStringSplit(list, ":", 0)))
>+ goto cleanup;
>+
>+ for (i = 0; token[i]; i += 2) {
>+ if (!token[i] || !token[i + 1] ||
Double check for "token[i]"; it'd be easier to do:
for (i = 0; token[i] && token[i + 1]; i += 2) {
...
}
>+ STREQ(token[i], "") || STREQ(token[i + 1], "")) {
>+ virReportError(VIR_ERR_INTERNAL_ERROR,
>+ _("Invalid --with-loader-nvram list: %s"),
>+ list);
>+ goto cleanup;
But erroring out here is maybe even more ugly than that bash parsing
in configure.ac :( There really is no other option to check this
built-time? Can we at least do something like:
l="$(echo "$with_loader_nvram" | tr ':' '\n' | wc -l)"
test $((l % 2)) -eq 0 || echo ERROR
this only checks that there's even number of parameters when split by
':', but it works in dash (and csh should be fine too, but I haven't
tested that). And the only thing you were checking was the number of
parameters, so this has the same meaning and it's done compile-time.
>+ }
>+ }
>+
>+ if (i) {
>+ if (VIR_ALLOC_N(cfg->loader, (i + 1) / 2) < 0 ||
>+ VIR_ALLOC_N(cfg->nvram, (i + 1) / 2) < 0)
>+ goto cleanup;
>+ cfg->nloader = (i + 1) / 2;
>+
>+ while (i) {
>+ if (VIR_STRDUP(cfg->loader[(i - 1) / 2 ], token[i - 2]) < 0 ||
>+ VIR_STRDUP(cfg->nvram[(i - 1) / 2], token[i - 1]) < 0)
You are not checking whether token[i] is '\0', but I don't know
whether that breaks later in the code or not.
Anyway, if something like this happens, I think working around that
and just printing a warning would be better. You can behave like if
the file does not exist -- we don't quit the daemon/driver in that
case, do we?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150126/b22a2aa3/attachment-0001.sig>
More information about the libvir-list
mailing list