[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
signature.asc
Description: OpenPGP digital signature
[Qemu-devel] [PATCH V21 4/7] Build the TPM frontend code, Stefan Berger, 2013/02/08
[Qemu-devel] [PATCH V21 2/7] Add TPM (frontend) hardware interface (TPM TIS) to QEMU, Stefan Berger, 2013/02/08