qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH V21 1/7] Support for TPM command line options


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH V21 1/7] Support for TPM command line options
Date: Fri, 08 Feb 2013 15:01:49 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 02/08/2013 02:42 PM, Stefan Berger wrote:
> This patch adds support for TPM command line options.
> The command line options supported here are
> 
> ./qemu-... -tpmdev passthrough,path=<path to TPM device>,id=<id>
>            -device tpm-tis,tpmdev=<id>
> 
> and
> 
> ./qemu-... -tpmdev ?

I though we preferred '-tpmdev help' instead of '-tpmdev ?' these days,
as that doesn't need shell quoting.

> 
> where the latter works similar to -soundhw ? and shows a list of
> available TPM backends (for example 'passthrough').

What is the QMP counterpart command for listing all possible TPM
backends?  Libvirt refuses to use command-line probing since qemu 1.3,
so we need some way for libvirt to get at the same list from QMP without
having to use '-tpmdev ?'.


> +++ b/qapi-schema.json
> @@ -3184,3 +3184,59 @@
>  # Since: 1.4
>  ##
>  { 'command': 'chardev-remove', 'data': {'id': 'str'} }
> +
> +##
> +# @TpmModel
> +#
> +# An enumeration of TPM models.
> +#
> +# @tpm-tis: TPM TIS model
> +#
> +# Since: 1.5
> +##
> +{ 'enum': 'TpmModel',
> +  'data': [ 'tpm-tis' ] }
> +
> +##
> +# @TpmType
> +#
> +# An enumeration of TPM types.
> +#
> +# @passthrough: TPM passthrough
> +#
> +# Since: 1.5
> +##
> +{ 'enum': 'TpmType',
> +  'data': [ 'passthrough' ] }
> +
> +##
> +# @TpmInfo:
> +#
> +# Information about the TPM
> +#
> +# @model: The TPM frontend model, i.e., tpm-tis
> +#
> +# @id: The ID of the TPM
> +#
> +# @type: The type of TPM backend, i.e., passthrough
> +#
> +# @path: #optional Path to the TPM backend device
> +#
> +# @cancel_path: #optional Path to TPM backend device's cancel sysfs entry

Prefer '-' over '_' in QMP; this should be cancel-path.

> +#
> +# Since: 1.5
> +##
> +{ 'type': 'TPMInfo',
> +  'data': {'model': 'TpmModel', 'id': 'str', 'type': 'TpmType', '*path': 
> 'str',
> +           '*cancel_path': 'str' } }

Is this a case where the choice of which optional parameters are present
depends on which model was in use?  That is, if we add a new model that
uses a new field, would it be better to have a union type, something like:

{ 'type': 'TPMTis', 'data': {'path':'str', '*cancel-path':'str'} }
{ 'union': 'TPMBackend',
  'data': { 'tpm-tis' : 'TPMTis',
            'tpm-future': 'TPMFUture' } }
{ 'type': 'TPMInfo',
  'data': { 'id': 'str', 'type': 'TpmType', 'model': 'TPMBackend' } }

so that the user sees:
{ 'id': 'tpm0', 'type':'passthrough',
  'model': { 'type':'tpm-tis', 'data':{'path':'/dev/tpm'} } }

not necessarily better, just food for thought.

> +Options to each backend are described below.
> +
> +Use ? to print all available TPM backend types.
> address@hidden
> +qemu -tpmdev ?

Again, new code should prefer 'help' rather than '?' from the command line.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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