qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH V4 01/10] Support for TPM command line options


From: Serge E. Hallyn
Subject: Re: [Qemu-devel] [PATCH V4 01/10] Support for TPM command line options
Date: Fri, 6 May 2011 15:23:32 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

Quoting Stefan Berger (address@hidden):
> This patch adds support for TPM command line options.
> The command line supported here (considering the libtpms based
> backend) are
> 
> ./qemu-... -tpm type=<type>,path=<path to blockstorage file>,
> 
> and
> 
> ./qemu-... -tpm ?
>
> where the latter works similar to -soundhw ? and shows a list of
> available TPM backends (i.e., libtpms-based, Xen).
> 
> Only the 'type' is interpreted in arch_init.c. Using this parameter,
> the backend is chosen, i.e., 'builtin' for the libtpms-based
> builtin TPM. The interpretation of the other parameters along with
> determining whether enough parameters were provided is pushed into
> the backend driver, which needs to implement the interface function
> 'handle_options' and return true if the VM can be started or 'false'
> if not enough or bad parameters were provided.
> 
> v4:
>  - coding style fixes
> 
> v3:
>  - added hw/tpm_tis.h to this patch so Qemu compiles at this stage
> 
> Signed-off-by: Stefan Berger <address@hidden>

Thanks, Stefan.  Two nits:

> +static QemuOptsList qemu_tpm_opts = {
> +    .name = "tpm",
> +    .head = QTAILQ_HEAD_INITIALIZER(qemu_tpm_opts.head),
> +    .desc = {
> +        {
> +            .name = "type",
> +            .type = QEMU_OPT_STRING,
> +            .help = "Type of TPM backend",
> +        },
> +        {
> +            .name = "path",
> +            .type = QEMU_OPT_STRING,
> +            .help = "Persitent storage for TPM state",

Persistent.

...

> +# else /* CONFIG_TPM */
> +
> +void select_tpm(const char *optarg)
> +{
> +    (void)optarg;
> +}

I realize this should never get called if !CONFIG_TPM, but that still
doesn't seem like cause to go directly calling a potentially NULL
string.

Otherwise, fwiw

Acked-by: Serge Hallyn <address@hidden>

thanks,
-serge



reply via email to

[Prev in Thread] Current Thread [Next in Thread]