7:06 a.m.
Hello,
This series implements a new device type for Libvirt called
"TPM Proxy". This device acts as a proxy for TPM requisitions
that the guest can make for an existing TPM Resource Manager
in the host. The TPM Resource Manager multiplexes TPM access
to multiple processes, allowing more than one process (guest)
to use the host TPM at the same time.
A guest using a TPM Proxy device does not have access to all
possible TPM features. In that case the guest will need to
assign a vTPM device (tpm-spapr for PPC64). There is no restrictions
of using both a vTPM and a TPM Proxy device at the same time,
but only one TPM Proxy is allowed per guest.
At this moment, this device exists only for QEMU pSeries guests.
A "model" field was added device to allow more models to be added
when/if other architectures implements it.
Daniel Henrique Barboza (8):
docs: documentation and schema for the new TPM Proxy device
qemu: Extend QEMU capabilities with 'spapr-tpm-proxy'
conf, qemu: adding VIR_DOMAIN_DEVICE_TPMPROXY device
domain_conf.c: XML parsing for VIR_DOMAIN_DEVICE_TPMPROXY
tests: add test for domain XML with TPM Proxy device model
qemu: build command line for the TPM Proxy device
tests/qemuxml2argvtest.c: add TPM Proxy command line test
docs/news.xml: update for the new TPM Proxy device
docs/formatdomain.html.in | 42 +++++
docs/news.xml | 14 ++
docs/schemas/domaincommon.rng | 18 ++
src/conf/domain_capabilities.c | 1 +
src/conf/domain_conf.c | 160 ++++++++++++++++++
src/conf/domain_conf.h | 18 ++
src/conf/virconftypes.h | 3 +
src/libvirt_private.syms | 2 +
src/qemu/qemu_alias.c | 16 ++
src/qemu/qemu_capabilities.c | 2 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 21 +++
src/qemu/qemu_domain.c | 14 ++
src/qemu/qemu_domain_address.c | 2 +
src/qemu/qemu_driver.c | 5 +
src/qemu/qemu_hotplug.c | 3 +
src/qemu/qemu_validate.c | 37 ++++
.../qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 +
.../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 +
tests/qemuxml2argvdata/ppc64-tpmproxy.args | 28 +++
tests/qemuxml2argvdata/ppc64-tpmproxy.xml | 31 ++++
tests/qemuxml2argvtest.c | 4 +
tests/qemuxml2xmloutdata/ppc64-tpmproxy.xml | 37 ++++
tests/qemuxml2xmltest.c | 4 +
24 files changed, 465 insertions(+)
create mode 100644 tests/qemuxml2argvdata/ppc64-tpmproxy.args
create mode 100644 tests/qemuxml2argvdata/ppc64-tpmproxy.xml
create mode 100644 tests/qemuxml2xmloutdata/ppc64-tpmproxy.xml
--
2.26.2
7:06 a.m.
New subject: [PATCH v1 1/8] docs: documentation and schema for the new TPM Proxy device
QEMU 4.1.0 introduced a new device type called TPM Proxy, currently
implemented by PPC64 guests via a new virtual device called
'spapr-tpm-proxy' (see QEMU 0fb6bd073230 for more info).
The TPM Proxy device interacts with a TPM Resource Manager, a host
device capable of multiplexing the host TPM with multiple processes.
This allows multiple guests to access some TPM features at the
same time. Note that this mode of operation does not provide
full TPM features to be available for the guest - for that case
the guest still needs to assign a vTPM device (tpm-spapr for
PPC64 guests). Although redundant, there is currently no technical
limitation for a guest to assign both a vTPM and a TPM Proxy at the
same time.
This patch adds documentation and schema for the new TPM Proxy device.
An example of a TPM Proxy device connected to a TPM Resource Manager
'/dev/tpmrm0' will look like this:
<tpmproxy model='spapr-tpm-proxy'>
<device path='/dev/tpmrm0'/>
</tpmproxy>
Signed-off-by: Daniel Henrique Barboza <danielhb413(a)gmail.com>
---
docs/formatdomain.html.in | 42 +++++++++++++++++++++++++++++++++++
docs/schemas/domaincommon.rng | 18 +++++++++++++++
2 files changed, 60 insertions(+)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 23eb029234..650e2a8c6e 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -8849,6 +8849,48 @@ qemu-kvm -net nic,model=? /dev/null
</dd>
</dl>
+ <h4><a id="elementsTpmProxy">TPM Proxy
device</a></h4>
+
+ <p>
+ The TPM Proxy device allows a QEMU guest to interact with an
+ existing TPM Resource Manager in the host. A TPM Resource Manager
+ enables a TPM device to be securely multiplexed across several
+ guests. Only one TPM Proxy device is allowed per guest.
+ </p>
+ <p>
+ A guest using the TPM Proxy device does not have access to all the
+ features a TPM device provides. This means that a guest can have both
+ a TPM Proxy and a TPM device assigned at the same time.
+ </p>
+ <p>
+ The TPM Proxy device is currently available only for pSeries guests.
+ <span class="since">since 6.4.0</span>
+ </p>
+ <p>
+ Example: usage of the TPM Proxy device
+ </p>
+<pre>
+...
+<devices>
+ <tpmproxy model='spapr-tpm-proxy'>
+ <device path='/dev/tpmrm0'/>
+ </tpmproxy>
+</devices>
+...
+</pre>
+
+ <dl>
+ <dt><code>model</code></dt>
+ <dd>
+ <p>
+ The <code>model</code> attribute specifies what device
+ model QEMU provides to the guest. If no model name is provided,
+ <code>spapr-tpm-proxy</code> will automatically be chosen for
+ PPC64 architectures.
+ </p>
+ </dd>
+ </dl>
+
<h4><a id="elementsNVRAM">NVRAM device</a></h4>
<p>
nvram device is always added to pSeries guest on PPC64, and its address
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index 9d60b090f3..44bbd92244 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -4676,6 +4676,23 @@
</optional>
</define>
+ <define name="tpmproxy">
+ <element name="tpmproxy">
+ <optional>
+ <attribute name="model">
+ <choice>
+ <value>spapr-tpm-proxy</value>
+ </choice>
+ </attribute>
+ </optional>
+ <element name="device">
+ <attribute name="path">
+ <ref name="filePath"/>
+ </attribute>
+ </element>
+ </element>
+ </define>
+
<define name="vsock">
<element name="vsock">
<optional>
@@ -5279,6 +5296,7 @@
<ref name="tpm"/>
<ref name="shmem"/>
<ref name="memorydev"/>
+ <ref name="tpmproxy"/>
</choice>
</zeroOrMore>
<optional>
--
2.26.2
3:30 p.m.
New subject: [PATCH v1 1/8] docs: documentation and schema for the new TPM Proxy device
On 5/8/20 8:06 AM, Daniel Henrique Barboza wrote:
QEMU 4.1.0 introduced a new device type called TPM Proxy, currently
implemented by PPC64 guests via a new virtual device called
'spapr-tpm-proxy' (see QEMU 0fb6bd073230 for more info).
The TPM Proxy device interacts with a TPM Resource Manager, a host
device capable of multiplexing the host TPM with multiple processes.
This allows multiple guests to access some TPM features at the
same time. Note that this mode of operation does not provide
full TPM features to be available for the guest - for that case
the guest still needs to assign a vTPM device (tpm-spapr for
PPC64 guests). Although redundant, there is currently no technical
limitation for a guest to assign both a vTPM and a TPM Proxy at the
same time.
This patch adds documentation and schema for the new TPM Proxy device.
An example of a TPM Proxy device connected to a TPM Resource Manager
'/dev/tpmrm0' will look like this:
<tpmproxy model='spapr-tpm-proxy'>
<device path='/dev/tpmrm0'/>
</tpmproxy>
We already have:
<backend type='passthrough'>
<device path='/dev/tpm0'/>
</backend>
Now what is the difference between this tpm-proxy device using
/dev/tpmrm0 and having the existing passthrough device use /dev/tpmrm0?
Is there any useful filtering going on by the tpm-proxy device? If not,
why not use passthrough with /dev/tpmrm0?
Stefan
8:22 p.m.
New subject: [PATCH v1 1/8] docs: documentation and schema for the new TPM Proxy device
On Fri, May 08, 2020 at 04:30:09PM -0400, Stefan Berger wrote:
On 5/8/20 8:06 AM, Daniel Henrique Barboza wrote:
> QEMU 4.1.0 introduced a new device type called TPM Proxy, currently
> implemented by PPC64 guests via a new virtual device called
> 'spapr-tpm-proxy' (see QEMU 0fb6bd073230 for more info).
>
> The TPM Proxy device interacts with a TPM Resource Manager, a host
> device capable of multiplexing the host TPM with multiple processes.
> This allows multiple guests to access some TPM features at the
> same time. Note that this mode of operation does not provide
> full TPM features to be available for the guest - for that case
> the guest still needs to assign a vTPM device (tpm-spapr for
> PPC64 guests). Although redundant, there is currently no technical
> limitation for a guest to assign both a vTPM and a TPM Proxy at the
> same time.
>
> This patch adds documentation and schema for the new TPM Proxy device.
> An example of a TPM Proxy device connected to a TPM Resource Manager
> '/dev/tpmrm0' will look like this:
>
> <tpmproxy model='spapr-tpm-proxy'>
> <device path='/dev/tpmrm0'/>
> </tpmproxy>
We already have:
<backend type='passthrough'>
<device path='/dev/tpm0'/>
</backend>
Now what is the difference between this tpm-proxy device using /dev/tpmrm0
and having the existing passthrough device use /dev/tpmrm0? Is there any
useful filtering going on by the tpm-proxy device? If not, why not use
passthrough with /dev/tpmrm0?
It's a different guest side interface, the H_TPM_COMM hypercall
instead of the other PAPR TPM interface. To which "why?" is a very
good question, but it's there now, so there's not much we can do about
it.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
4:57 a.m.
New subject: [PATCH v1 1/8] docs: documentation and schema for the new TPM Proxy device
On Mon, May 11, 2020 at 11:22:57AM +1000, David Gibson wrote:
On Fri, May 08, 2020 at 04:30:09PM -0400, Stefan Berger wrote:
> On 5/8/20 8:06 AM, Daniel Henrique Barboza wrote:
> > QEMU 4.1.0 introduced a new device type called TPM Proxy, currently
> > implemented by PPC64 guests via a new virtual device called
> > 'spapr-tpm-proxy' (see QEMU 0fb6bd073230 for more info).
> >
> > The TPM Proxy device interacts with a TPM Resource Manager, a host
> > device capable of multiplexing the host TPM with multiple processes.
> > This allows multiple guests to access some TPM features at the
> > same time. Note that this mode of operation does not provide
> > full TPM features to be available for the guest - for that case
> > the guest still needs to assign a vTPM device (tpm-spapr for
> > PPC64 guests). Although redundant, there is currently no technical
> > limitation for a guest to assign both a vTPM and a TPM Proxy at the
> > same time.
> >
> > This patch adds documentation and schema for the new TPM Proxy device.
> > An example of a TPM Proxy device connected to a TPM Resource Manager
> > '/dev/tpmrm0' will look like this:
> >
> > <tpmproxy model='spapr-tpm-proxy'>
> > <device path='/dev/tpmrm0'/>
> > </tpmproxy>
>
> We already have:
>
> <backend type='passthrough'>
> <device path='/dev/tpm0'/>
> </backend>
>
> Now what is the difference between this tpm-proxy device using /dev/tpmrm0
> and having the existing passthrough device use /dev/tpmrm0? Is there any
> useful filtering going on by the tpm-proxy device? If not, why not use
> passthrough with /dev/tpmrm0?
It's a different guest side interface, the H_TPM_COMM hypercall
instead of the other PAPR TPM interface. To which "why?" is a very
good question, but it's there now, so there's not much we can do about
it.
That's ok. Even though its a different guest interface, it is still
conceptually a TPM device at a high level, so we should be reusing
the existing <tpm> device type. At most we should add a new backend
type
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
6:26 a.m.
New subject: [PATCH v1 1/8] docs: documentation and schema for the new TPM Proxy device
On 5/11/20 6:57 AM, Daniel P. Berrangé wrote:
On Mon, May 11, 2020 at 11:22:57AM +1000, David Gibson wrote:
[...]
> It's a different guest side interface, the H_TPM_COMM
hypercall
> instead of the other PAPR TPM interface. To which "why?" is a very
> good question, but it's there now, so there's not much we can do about
> it.
That's ok. Even though its a different guest interface, it is still
conceptually a TPM device at a high level, so we should be reusing
the existing <tpm> device type. At most we should add a new backend
type
I think adding a new backend type is sensible. Re-using the passthrough type
and making the differentiation with 'model', for a device that doesn't
operate exactly as a regular vTPM but can coexist with other vTPM devices,
will make for a lot of IFs in the code.
DHB
Regards,
Daniel
6:28 a.m.
New subject: [PATCH v1 1/8] docs: documentation and schema for the new TPM Proxy device
On Mon, May 11, 2020 at 08:26:53AM -0300, Daniel Henrique Barboza wrote:
On 5/11/20 6:57 AM, Daniel P. Berrangé wrote:
> On Mon, May 11, 2020 at 11:22:57AM +1000, David Gibson wrote:
[...]
> > It's a different guest side interface, the H_TPM_COMM hypercall
> > instead of the other PAPR TPM interface. To which "why?" is a very
> > good question, but it's there now, so there's not much we can do about
> > it.
>
> That's ok. Even though its a different guest interface, it is still
> conceptually a TPM device at a high level, so we should be reusing
> the existing <tpm> device type. At most we should add a new backend
> type
I think adding a new backend type is sensible. Re-using the passthrough type
and making the differentiation with 'model', for a device that doesn't
operate exactly as a regular vTPM but can coexist with other vTPM devices,
will make for a lot of IFs in the code.
Currently libvirt only allows a single <tpm>, but we can trivially
lift that restriction to allow multiple if desired too.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
6:50 a.m.
New subject: [PATCH v1 1/8] docs: documentation and schema for the new TPM Proxy device
On 5/11/20 8:28 AM, Daniel P. Berrangé wrote:
On Mon, May 11, 2020 at 08:26:53AM -0300, Daniel Henrique Barboza
wrote:
>
>
> On 5/11/20 6:57 AM, Daniel P. Berrangé wrote:
>> On Mon, May 11, 2020 at 11:22:57AM +1000, David Gibson wrote:
> [...]
>>> It's a different guest side interface, the H_TPM_COMM hypercall
>>> instead of the other PAPR TPM interface. To which "why?" is a
very
>>> good question, but it's there now, so there's not much we can do
about
>>> it.
>>
>> That's ok. Even though its a different guest interface, it is still
>> conceptually a TPM device at a high level, so we should be reusing
>> the existing <tpm> device type. At most we should add a new backend
>> type
>
> I think adding a new backend type is sensible. Re-using the passthrough type
> and making the differentiation with 'model', for a device that doesn't
> operate exactly as a regular vTPM but can coexist with other vTPM devices,
> will make for a lot of IFs in the code.
Currently libvirt only allows a single <tpm>, but we can trivially
lift that restriction to allow multiple if desired too.
I don't believe it'll be necessary. Since it's only this TPM Proxy device
that
can coexist with other TPMs, my idea is to do what I did here in this series,
but instead of creating a new device type I'll re-use the existing TPM device
in a 'tpmproxy' pointer in the domain for this case.
I'll still thinking about whether a new backend type is warranted or not. For
this PPC64 case alone it'll be simpler to just add a new 'model' called
'spapr-tpm'-proxy' for the existing TPM passthrough type. Creating a new
backend type makes it easier to add other TPM Proxy devices when other archs
implement it though.
Thanks,
DHB
Regards,
Daniel
11:29 a.m.
New subject: [PATCH v1 1/8] docs: documentation and schema for the new TPM Proxy device
On 5/11/20 8:50 AM, Daniel Henrique Barboza wrote:
On 5/11/20 8:28 AM, Daniel P. Berrangé wrote:
> On Mon, May 11, 2020 at 08:26:53AM -0300, Daniel Henrique Barboza wrote:
>>
>>
>> On 5/11/20 6:57 AM, Daniel P. Berrangé wrote:
>>> On Mon, May 11, 2020 at 11:22:57AM +1000, David Gibson wrote:
>> [...]
[...]
>
> Currently libvirt only allows a single <tpm>, but we can trivially
> lift that restriction to allow multiple if desired too.
I don't believe it'll be necessary. Since it's only this TPM Proxy device
that
can coexist with other TPMs, my idea is to do what I did here in this series,
but instead of creating a new device type I'll re-use the existing TPM device
in a 'tpmproxy' pointer in the domain for this case.
I'll still thinking about whether a new backend type is warranted or not. For
this PPC64 case alone it'll be simpler to just add a new 'model' called
'spapr-tpm'-proxy' for the existing TPM passthrough type. Creating a new
backend type makes it easier to add other TPM Proxy devices when other archs
implement it though.
Update: I tried it out the new "backend" approach and didn't enjoy the
results.
It ended up replicating a large amount of existing cgroup/dac/selinux code that
handles the existing "passthrough" backend and, all said and done, it didn't
alleviate
that much the parsing/format XML logic comparing to the alternative.
I chose then to go to the simpler route - adding a new 'passthrough' model called
'spapr-tpm-proxy'. This will not scale well if/when more TPM proxies devices are
added in the future, but we can cross that bridge when we come to it.
DHB
Thanks,
DHB
>
> Regards,
> Daniel
>
7:06 p.m.
New subject: [PATCH v1 1/8] docs: documentation and schema for the new TPM Proxy device
On Tue, May 12, 2020 at 01:29:43PM -0300, Daniel Henrique Barboza wrote:
On 5/11/20 8:50 AM, Daniel Henrique Barboza wrote:
>
>
> On 5/11/20 8:28 AM, Daniel P. Berrangé wrote:
> > On Mon, May 11, 2020 at 08:26:53AM -0300, Daniel Henrique Barboza wrote:
> > >
> > >
> > > On 5/11/20 6:57 AM, Daniel P. Berrangé wrote:
> > > > On Mon, May 11, 2020 at 11:22:57AM +1000, David Gibson wrote:
> > > [...]
[...]
> >
> > Currently libvirt only allows a single <tpm>, but we can trivially
> > lift that restriction to allow multiple if desired too.
>
> I don't believe it'll be necessary. Since it's only this TPM Proxy
device that
> can coexist with other TPMs, my idea is to do what I did here in this series,
> but instead of creating a new device type I'll re-use the existing TPM device
> in a 'tpmproxy' pointer in the domain for this case.
>
> I'll still thinking about whether a new backend type is warranted or not. For
> this PPC64 case alone it'll be simpler to just add a new 'model' called
> 'spapr-tpm'-proxy' for the existing TPM passthrough type. Creating a
new
> backend type makes it easier to add other TPM Proxy devices when other archs
> implement it though.
Update: I tried it out the new "backend" approach and didn't enjoy the
results.
It ended up replicating a large amount of existing cgroup/dac/selinux code that
handles the existing "passthrough" backend and, all said and done, it
didn't alleviate
that much the parsing/format XML logic comparing to the alternative.
I chose then to go to the simpler route - adding a new 'passthrough' model
called
'spapr-tpm-proxy'. This will not scale well if/when more TPM proxies devices are
added in the future, but we can cross that bridge when we come to
it.
TBH, I think that's unlikely to happen. The TPM proxy exists because
of the design of POWER's secure VM model, and because it was easy to
add an hcall to PAPR for this, without thinking how it would integrate
with other TPM devices or PAPR's existing / concurrently designed vTPM
interface. I don't think there's any general reason you'd want a
device like this, distinct from just a vTPM.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
7:12 p.m.
New subject: [PATCH v1 1/8] docs: documentation and schema for the new TPM Proxy device
On Wed, May 13, 2020 at 10:06:23AM +1000, David Gibson wrote:
On Tue, May 12, 2020 at 01:29:43PM -0300, Daniel Henrique Barboza
wrote:
>
>
> On 5/11/20 8:50 AM, Daniel Henrique Barboza wrote:
> >
> >
> > On 5/11/20 8:28 AM, Daniel P. Berrangé wrote:
> > > On Mon, May 11, 2020 at 08:26:53AM -0300, Daniel Henrique Barboza wrote:
> > > >
> > > >
> > > > On 5/11/20 6:57 AM, Daniel P. Berrangé wrote:
> > > > > On Mon, May 11, 2020 at 11:22:57AM +1000, David Gibson wrote:
> > > > [...]
> [...]
> > >
> > > Currently libvirt only allows a single <tpm>, but we can trivially
> > > lift that restriction to allow multiple if desired too.
> >
> > I don't believe it'll be necessary. Since it's only this TPM Proxy
device that
> > can coexist with other TPMs, my idea is to do what I did here in this series,
> > but instead of creating a new device type I'll re-use the existing TPM
device
> > in a 'tpmproxy' pointer in the domain for this case.
> >
> > I'll still thinking about whether a new backend type is warranted or not.
For
> > this PPC64 case alone it'll be simpler to just add a new 'model'
called
> > 'spapr-tpm'-proxy' for the existing TPM passthrough type. Creating
a new
> > backend type makes it easier to add other TPM Proxy devices when other archs
> > implement it though.
>
> Update: I tried it out the new "backend" approach and didn't enjoy the
results.
> It ended up replicating a large amount of existing cgroup/dac/selinux code that
> handles the existing "passthrough" backend and, all said and done, it
didn't alleviate
> that much the parsing/format XML logic comparing to the alternative.
>
> I chose then to go to the simpler route - adding a new 'passthrough' model
called
> 'spapr-tpm-proxy'. This will not scale well if/when more TPM proxies devices
are
> added in the future, but we can cross that bridge when we come to
> it.
TBH, I think that's unlikely to happen. The TPM proxy exists because
of the design of POWER's secure VM model, and because it was easy to
add an hcall to PAPR for this, without thinking how it would integrate
with other TPM devices or PAPR's existing / concurrently designed vTPM
interface. I don't think there's any general reason you'd want a
device like this, distinct from just a vTPM.
Indeed, arguably, this would be better modelled by just some sort of
machine or firmware feature flag, rather than a "device" as such.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
10:21 a.m.
New subject: [PATCH v1 1/8] docs: documentation and schema for the new TPM Proxy device
On 5/11/20 7:28 AM, Daniel P. Berrangé wrote:
On Mon, May 11, 2020 at 08:26:53AM -0300, Daniel Henrique Barboza
wrote:
>
> On 5/11/20 6:57 AM, Daniel P. Berrangé wrote:
>> On Mon, May 11, 2020 at 11:22:57AM +1000, David Gibson wrote:
> [...]
>>> It's a different guest side interface, the H_TPM_COMM hypercall
>>> instead of the other PAPR TPM interface. To which "why?" is a
very
>>> good question, but it's there now, so there's not much we can do
about
>>> it.
>> That's ok. Even though its a different guest interface, it is still
>> conceptually a TPM device at a high level, so we should be reusing
>> the existing <tpm> device type. At most we should add a new backend
>> type
> I think adding a new backend type is sensible. Re-using the passthrough type
> and making the differentiation with 'model', for a device that doesn't
> operate exactly as a regular vTPM but can coexist with other vTPM devices,
> will make for a lot of IFs in the code.
Currently libvirt only allows a single <tpm>, but we can trivially
lift that restriction to allow multiple if desired too.
QEMU won't accept multiple TIS or CRB devices, though.
Regards,
Daniel
10:53 a.m.
New subject: [PATCH v1 1/8] docs: documentation and schema for the new TPM Proxy device
On Tue, May 12, 2020 at 11:21:52AM -0400, Stefan Berger wrote:
On 5/11/20 7:28 AM, Daniel P. Berrangé wrote:
> On Mon, May 11, 2020 at 08:26:53AM -0300, Daniel Henrique Barboza wrote:
> >
> > On 5/11/20 6:57 AM, Daniel P. Berrangé wrote:
> > > On Mon, May 11, 2020 at 11:22:57AM +1000, David Gibson wrote:
> > [...]
> > > > It's a different guest side interface, the H_TPM_COMM hypercall
> > > > instead of the other PAPR TPM interface. To which "why?"
is a very
> > > > good question, but it's there now, so there's not much we can
do about
> > > > it.
> > > That's ok. Even though its a different guest interface, it is still
> > > conceptually a TPM device at a high level, so we should be reusing
> > > the existing <tpm> device type. At most we should add a new backend
> > > type
> > I think adding a new backend type is sensible. Re-using the passthrough type
> > and making the differentiation with 'model', for a device that
doesn't
> > operate exactly as a regular vTPM but can coexist with other vTPM devices,
> > will make for a lot of IFs in the code.
> Currently libvirt only allows a single <tpm>, but we can trivially
> lift that restriction to allow multiple if desired too.
QEMU won't accept multiple TIS or CRB devices, though.
The commit message says you can do 2 at a time:
"Although redundant, there is currently no technical
limitation for a guest to assign both a vTPM and a TPM Proxy at the
same time."
is that text not accurate ?
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
11:21 a.m.
New subject: [PATCH v1 1/8] docs: documentation and schema for the new TPM Proxy device
On 5/12/20 12:53 PM, Daniel P. Berrangé wrote:
On Tue, May 12, 2020 at 11:21:52AM -0400, Stefan Berger wrote:
> On 5/11/20 7:28 AM, Daniel P. Berrangé wrote:
>> On Mon, May 11, 2020 at 08:26:53AM -0300, Daniel Henrique Barboza wrote:
>>>
>>> On 5/11/20 6:57 AM, Daniel P. Berrangé wrote:
>>>> On Mon, May 11, 2020 at 11:22:57AM +1000, David Gibson wrote:
>>> [...]
>>>>> It's a different guest side interface, the H_TPM_COMM hypercall
>>>>> instead of the other PAPR TPM interface. To which "why?"
is a very
>>>>> good question, but it's there now, so there's not much we can
do about
>>>>> it.
>>>> That's ok. Even though its a different guest interface, it is still
>>>> conceptually a TPM device at a high level, so we should be reusing
>>>> the existing <tpm> device type. At most we should add a new
backend
>>>> type
>>> I think adding a new backend type is sensible. Re-using the passthrough type
>>> and making the differentiation with 'model', for a device that
doesn't
>>> operate exactly as a regular vTPM but can coexist with other vTPM devices,
>>> will make for a lot of IFs in the code.
>> Currently libvirt only allows a single <tpm>, but we can trivially
>> lift that restriction to allow multiple if desired too.
>
>
> QEMU won't accept multiple TIS or CRB devices, though.
The commit message says you can do 2 at a time:
"Although redundant, there is currently no technical
limitation for a guest to assign both a vTPM and a TPM Proxy at the
same time."
is that text not accurate ?
It is. A TPM Proxy is not considered a TIS or CRB, so it's ok to mix it up
with another TPM device. The allowed combinations are:
- single vTPM device
- single TPM Proxy device
- a single vTPM + single TPM Proxy devices
Not allowed:
- 2 or more vTPM devices
- 2 or more TPM Proxy devices
DHB
Regards,
Daniel
11:44 a.m.
New subject: [PATCH v1 1/8] docs: documentation and schema for the new TPM Proxy device
On Tue, May 12, 2020 at 01:21:40PM -0300, Daniel Henrique Barboza wrote:
On 5/12/20 12:53 PM, Daniel P. Berrangé wrote:
> On Tue, May 12, 2020 at 11:21:52AM -0400, Stefan Berger wrote:
> > On 5/11/20 7:28 AM, Daniel P. Berrangé wrote:
> > > On Mon, May 11, 2020 at 08:26:53AM -0300, Daniel Henrique Barboza wrote:
> > > >
> > > > On 5/11/20 6:57 AM, Daniel P. Berrangé wrote:
> > > > > On Mon, May 11, 2020 at 11:22:57AM +1000, David Gibson wrote:
> > > > [...]
> > > > > > It's a different guest side interface, the H_TPM_COMM
hypercall
> > > > > > instead of the other PAPR TPM interface. To which
"why?" is a very
> > > > > > good question, but it's there now, so there's not
much we can do about
> > > > > > it.
> > > > > That's ok. Even though its a different guest interface, it
is still
> > > > > conceptually a TPM device at a high level, so we should be
reusing
> > > > > the existing <tpm> device type. At most we should add a
new backend
> > > > > type
> > > > I think adding a new backend type is sensible. Re-using the
passthrough type
> > > > and making the differentiation with 'model', for a device
that doesn't
> > > > operate exactly as a regular vTPM but can coexist with other vTPM
devices,
> > > > will make for a lot of IFs in the code.
> > > Currently libvirt only allows a single <tpm>, but we can trivially
> > > lift that restriction to allow multiple if desired too.
> >
> >
> > QEMU won't accept multiple TIS or CRB devices, though.
>
> The commit message says you can do 2 at a time:
>
> "Although redundant, there is currently no technical
> limitation for a guest to assign both a vTPM and a TPM Proxy at the
> same time."
>
> is that text not accurate ?
It is. A TPM Proxy is not considered a TIS or CRB, so it's ok to mix it up
with another TPM device. The allowed combinations are:
- single vTPM device
- single TPM Proxy device
- a single vTPM + single TPM Proxy devices
So we do need multiple <tpm> support in the XML for this last case
then.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
11:51 a.m.
New subject: [PATCH v1 1/8] docs: documentation and schema for the new TPM Proxy device
On 5/12/20 1:44 PM, Daniel P. Berrangé wrote:
On Tue, May 12, 2020 at 01:21:40PM -0300, Daniel Henrique Barboza
wrote:
>
>
> On 5/12/20 12:53 PM, Daniel P. Berrangé wrote:
>> On Tue, May 12, 2020 at 11:21:52AM -0400, Stefan Berger wrote:
>>> On 5/11/20 7:28 AM, Daniel P. Berrangé wrote:
>>>> On Mon, May 11, 2020 at 08:26:53AM -0300, Daniel Henrique Barboza wrote:
>>>>>
>>>>> On 5/11/20 6:57 AM, Daniel P. Berrangé wrote:
>>>>>> On Mon, May 11, 2020 at 11:22:57AM +1000, David Gibson wrote:
>>>>> [...]
>>>>>>> It's a different guest side interface, the H_TPM_COMM
hypercall
>>>>>>> instead of the other PAPR TPM interface. To which
"why?" is a very
>>>>>>> good question, but it's there now, so there's not
much we can do about
>>>>>>> it.
>>>>>> That's ok. Even though its a different guest interface, it is
still
>>>>>> conceptually a TPM device at a high level, so we should be
reusing
>>>>>> the existing <tpm> device type. At most we should add a new
backend
>>>>>> type
>>>>> I think adding a new backend type is sensible. Re-using the
passthrough type
>>>>> and making the differentiation with 'model', for a device
that doesn't
>>>>> operate exactly as a regular vTPM but can coexist with other vTPM
devices,
>>>>> will make for a lot of IFs in the code.
>>>> Currently libvirt only allows a single <tpm>, but we can trivially
>>>> lift that restriction to allow multiple if desired too.
>>>
>>>
>>> QEMU won't accept multiple TIS or CRB devices, though.
>>
>> The commit message says you can do 2 at a time:
>>
>> "Although redundant, there is currently no technical
>> limitation for a guest to assign both a vTPM and a TPM Proxy at the
>> same time."
>>
>> is that text not accurate ?
>
>
> It is. A TPM Proxy is not considered a TIS or CRB, so it's ok to mix it up
> with another TPM device. The allowed combinations are:
>
> - single vTPM device
> - single TPM Proxy device
> - a single vTPM + single TPM Proxy devices
So we do need multiple <tpm> support in the XML for this last case
then.
Indeed we do. Working on it ATM. The plan is for this kind of XML format to be valid:
<tpm model='tpm-tis'>
<backend type='passthrough'>
<device path='/dev/tpm0'/>
</backend>
</tpm>
<tpm model='spapr-tpm-proxy'>
<backend type='passthrough'>
<device path='/dev/tpmrm0'/>
</backend>
</tpm>
A TPM Proxy allows a second TPM device to be added, as long as it's not a second TPM
Proxy device.
Thanks,
DHB
Regards,
Daniel
11:52 a.m.
New subject: [PATCH v1 1/8] docs: documentation and schema for the new TPM Proxy device
On Tue, May 12, 2020 at 01:51:33PM -0300, Daniel Henrique Barboza wrote:
On 5/12/20 1:44 PM, Daniel P. Berrangé wrote:
> On Tue, May 12, 2020 at 01:21:40PM -0300, Daniel Henrique Barboza wrote:
> >
> >
> > On 5/12/20 12:53 PM, Daniel P. Berrangé wrote:
> > > On Tue, May 12, 2020 at 11:21:52AM -0400, Stefan Berger wrote:
> > > > On 5/11/20 7:28 AM, Daniel P. Berrangé wrote:
> > > > > On Mon, May 11, 2020 at 08:26:53AM -0300, Daniel Henrique
Barboza wrote:
> > > > > >
> > > > > > On 5/11/20 6:57 AM, Daniel P. Berrangé wrote:
> > > > > > > On Mon, May 11, 2020 at 11:22:57AM +1000, David Gibson
wrote:
> > > > > > [...]
> > > > > > > > It's a different guest side interface, the
H_TPM_COMM hypercall
> > > > > > > > instead of the other PAPR TPM interface. To
which "why?" is a very
> > > > > > > > good question, but it's there now, so
there's not much we can do about
> > > > > > > > it.
> > > > > > > That's ok. Even though its a different guest
interface, it is still
> > > > > > > conceptually a TPM device at a high level, so we
should be reusing
> > > > > > > the existing <tpm> device type. At most we
should add a new backend
> > > > > > > type
> > > > > > I think adding a new backend type is sensible. Re-using the
passthrough type
> > > > > > and making the differentiation with 'model', for a
device that doesn't
> > > > > > operate exactly as a regular vTPM but can coexist with
other vTPM devices,
> > > > > > will make for a lot of IFs in the code.
> > > > > Currently libvirt only allows a single <tpm>, but we can
trivially
> > > > > lift that restriction to allow multiple if desired too.
> > > >
> > > >
> > > > QEMU won't accept multiple TIS or CRB devices, though.
> > >
> > > The commit message says you can do 2 at a time:
> > >
> > > "Although redundant, there is currently no technical
> > > limitation for a guest to assign both a vTPM and a TPM Proxy at the
> > > same time."
> > >
> > > is that text not accurate ?
> >
> >
> > It is. A TPM Proxy is not considered a TIS or CRB, so it's ok to mix it up
> > with another TPM device. The allowed combinations are:
> >
> > - single vTPM device
> > - single TPM Proxy device
> > - a single vTPM + single TPM Proxy devices
>
> So we do need multiple <tpm> support in the XML for this last case
> then.
Indeed we do. Working on it ATM. The plan is for this kind of XML format to be valid:
<tpm model='tpm-tis'>
<backend type='passthrough'>
<device path='/dev/tpm0'/>
</backend>
</tpm>
<tpm model='spapr-tpm-proxy'>
<backend type='passthrough'>
<device path='/dev/tpmrm0'/>
</backend>
</tpm>
Right, that sounds ok.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
5:43 p.m.
New subject: [PATCH v1 1/8] docs: documentation and schema for the new TPM Proxy device
On 5/8/20 8:06 AM, Daniel Henrique Barboza wrote:
QEMU 4.1.0 introduced a new device type called TPM Proxy, currently
implemented by PPC64 guests via a new virtual device called
'spapr-tpm-proxy' (see QEMU 0fb6bd073230 for more info).
The TPM Proxy device interacts with a TPM Resource Manager, a host
device capable of multiplexing the host TPM with multiple processes.
This allows multiple guests to access some TPM features at the
same time. Note that this mode of operation does not provide
full TPM features to be available for the guest - for that case
the guest still needs to assign a vTPM device (tpm-spapr for
PPC64 guests). Although redundant, there is currently no technical
limitation for a guest to assign both a vTPM and a TPM Proxy at the
same time.
This patch adds documentation and schema for the new TPM Proxy device.
An example of a TPM Proxy device connected to a TPM Resource Manager
'/dev/tpmrm0' will look like this:
<tpmproxy model='spapr-tpm-proxy'>
<device path='/dev/tpmrm0'/>
</tpmproxy>
Signed-off-by: Daniel Henrique Barboza <danielhb413(a)gmail.com>
---
docs/formatdomain.html.in | 42 +++++++++++++++++++++++++++++++++++
docs/schemas/domaincommon.rng | 18 +++++++++++++++
2 files changed, 60 insertions(+)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 23eb029234..650e2a8c6e 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -8849,6 +8849,48 @@ qemu-kvm -net nic,model=? /dev/null
</dd>
</dl>
+ <h4><a id="elementsTpmProxy">TPM Proxy
device</a></h4>
+
+ <p>
+ The TPM Proxy device allows a QEMU guest to interact with an
+ existing TPM Resource Manager in the host. A TPM Resource Manager
+ enables a TPM device to be securely multiplexed across several
+ guests. Only one TPM Proxy device is allowed per guest.
I think you should mention SVMs here and that this is what this
extension is used for or are there other uses than secure VMs?
+ </p>
+ <p>
+ A guest using the TPM Proxy device does not have access to all the
+ features a TPM device provides. This means that a guest can have both
+ a TPM Proxy and a TPM device assigned at the same time.
And this TPM Proxy device only enables the H_COMM_TPM hypercall rather
than talking to /dev/tpm(rm)0 inside the SVM. I think this should be
clarified because otherwise people might confuse it with the passthrough
device that does expose /dev/tpm0 inside the VM for example.
+ </p>
+ <p>
+ The TPM Proxy device is currently available only for pSeries guests.
+ <span class="since">since 6.4.0</span>
+ </p>
+ <p>
+ Example: usage of the TPM Proxy device
+ </p>
+<pre>
+...
+<devices>
+ <tpmproxy model='spapr-tpm-proxy'>
+ <device path='/dev/tpmrm0'/>
+ </tpmproxy>
+</devices>
+...
+</pre>
+
+ <dl>
+ <dt><code>model</code></dt>
+ <dd>
+ <p>
+ The <code>model</code> attribute specifies what device
+ model QEMU provides to the guest. If no model name is provided,
+ <code>spapr-tpm-proxy</code> will automatically be chosen for
+ PPC64 architectures.
+ </p>
+ </dd>
+ </dl>
+
<h4><a id="elementsNVRAM">NVRAM device</a></h4>
<p>
nvram device is always added to pSeries guest on PPC64, and its address
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index 9d60b090f3..44bbd92244 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -4676,6 +4676,23 @@
</optional>
</define>
+ <define name="tpmproxy">
+ <element name="tpmproxy">
+ <optional>
+ <attribute name="model">
+ <choice>
+ <value>spapr-tpm-proxy</value>
+ </choice>
+ </attribute>
+ </optional>
+ <element name="device">
+ <attribute name="path">
+ <ref name="filePath"/>
+ </attribute>
+ </element>
+ </element>
+ </define>
+
<define name="vsock">
<element name="vsock">
<optional>
@@ -5279,6 +5296,7 @@
<ref name="tpm"/>
<ref name="shmem"/>
<ref name="memorydev"/>
+ <ref name="tpmproxy"/>
</choice>
</zeroOrMore>
<optional>
8:24 p.m.
New subject: [PATCH v1 1/8] docs: documentation and schema for the new TPM Proxy device
On Fri, May 08, 2020 at 06:43:20PM -0400, Stefan Berger wrote:
On 5/8/20 8:06 AM, Daniel Henrique Barboza wrote:
> QEMU 4.1.0 introduced a new device type called TPM Proxy, currently
> implemented by PPC64 guests via a new virtual device called
> 'spapr-tpm-proxy' (see QEMU 0fb6bd073230 for more info).
>
> The TPM Proxy device interacts with a TPM Resource Manager, a host
> device capable of multiplexing the host TPM with multiple processes.
> This allows multiple guests to access some TPM features at the
> same time. Note that this mode of operation does not provide
> full TPM features to be available for the guest - for that case
> the guest still needs to assign a vTPM device (tpm-spapr for
> PPC64 guests). Although redundant, there is currently no technical
> limitation for a guest to assign both a vTPM and a TPM Proxy at the
> same time.
>
> This patch adds documentation and schema for the new TPM Proxy device.
> An example of a TPM Proxy device connected to a TPM Resource Manager
> '/dev/tpmrm0' will look like this:
>
> <tpmproxy model='spapr-tpm-proxy'>
> <device path='/dev/tpmrm0'/>
> </tpmproxy>
>
> Signed-off-by: Daniel Henrique Barboza <danielhb413(a)gmail.com>
> ---
> docs/formatdomain.html.in | 42 +++++++++++++++++++++++++++++++++++
> docs/schemas/domaincommon.rng | 18 +++++++++++++++
> 2 files changed, 60 insertions(+)
>
> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
> index 23eb029234..650e2a8c6e 100644
> --- a/docs/formatdomain.html.in
> +++ b/docs/formatdomain.html.in
> @@ -8849,6 +8849,48 @@ qemu-kvm -net nic,model=? /dev/null
> </dd>
> </dl>
> + <h4><a id="elementsTpmProxy">TPM Proxy
device</a></h4>
> +
> + <p>
> + The TPM Proxy device allows a QEMU guest to interact with an
> + existing TPM Resource Manager in the host. A TPM Resource Manager
> + enables a TPM device to be securely multiplexed across several
> + guests. Only one TPM Proxy device is allowed per guest.
I think you should mention SVMs here and that this is what this extension is
used for or are there other uses than secure VMs?
Yes, I think talking about PEF secure VMs is a good idea. This could
theoretically be used for other things, but secure VMs is the only
actual user I know of.
> + </p>
> + <p>
> + A guest using the TPM Proxy device does not have access to all the
> + features a TPM device provides. This means that a guest can have both
> + a TPM Proxy and a TPM device assigned at the same time.
And this TPM Proxy device only enables the H_COMM_TPM hypercall rather than
talking to /dev/tpm(rm)0 inside the SVM. I think this should be clarified
because otherwise people might confuse it with the passthrough device that
does expose /dev/tpm0 inside the VM for example.
> + </p>
> + <p>
> + The TPM Proxy device is currently available only for pSeries guests.
> + <span class="since">since 6.4.0</span>
> + </p>
> + <p>
> + Example: usage of the TPM Proxy device
> + </p>
> +<pre>
> +...
> +<devices>
> + <tpmproxy model='spapr-tpm-proxy'>
> + <device path='/dev/tpmrm0'/>
> + </tpmproxy>
> +</devices>
> +...
> +</pre>
> +
> + <dl>
> + <dt><code>model</code></dt>
> + <dd>
> + <p>
> + The <code>model</code> attribute specifies what device
> + model QEMU provides to the guest. If no model name is provided,
> + <code>spapr-tpm-proxy</code> will automatically be chosen
for
> + PPC64 architectures.
> + </p>
> + </dd>
> + </dl>
> +
> <h4><a id="elementsNVRAM">NVRAM
device</a></h4>
> <p>
> nvram device is always added to pSeries guest on PPC64, and its address
> diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
> index 9d60b090f3..44bbd92244 100644
> --- a/docs/schemas/domaincommon.rng
> +++ b/docs/schemas/domaincommon.rng
> @@ -4676,6 +4676,23 @@
> </optional>
> </define>
> + <define name="tpmproxy">
> + <element name="tpmproxy">
> + <optional>
> + <attribute name="model">
> + <choice>
> + <value>spapr-tpm-proxy</value>
> + </choice>
> + </attribute>
> + </optional>
> + <element name="device">
> + <attribute name="path">
> + <ref name="filePath"/>
> + </attribute>
> + </element>
> + </element>
> + </define>
> +
> <define name="vsock">
> <element name="vsock">
> <optional>
> @@ -5279,6 +5296,7 @@
> <ref name="tpm"/>
> <ref name="shmem"/>
> <ref name="memorydev"/>
> + <ref name="tpmproxy"/>
> </choice>
> </zeroOrMore>
> <optional>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
7:06 a.m.
New subject: [PATCH v1 2/8] qemu: Extend QEMU capabilities with 'spapr-tpm-proxy'
Expose the TPM Proxy support for PPC64 guests by creating a new
cap called QEMU_CAPS_DEVICE_SPAPR_TPM_PROXY.
Signed-off-by: Daniel Henrique Barboza <danielhb413(a)gmail.com>
---
src/qemu/qemu_capabilities.c | 2 ++
src/qemu/qemu_capabilities.h | 1 +
tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 +
tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 +
4 files changed, 5 insertions(+)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 2c6e36685e..dcc1886954 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -580,6 +580,7 @@ VIR_ENUM_IMPL(virQEMUCaps,
"machine.pseries.cap-sbbc",
"machine.pseries.cap-ibs",
"tcg",
+ "spapr-tpm-proxy",
);
@@ -1301,6 +1302,7 @@ struct virQEMUCapsStringFlags virQEMUCapsObjectTypes[] = {
{ "tpm-spapr", QEMU_CAPS_DEVICE_TPM_SPAPR },
{ "vhost-user-fs-device", QEMU_CAPS_DEVICE_VHOST_USER_FS },
{ "tcg-accel", QEMU_CAPS_TCG },
+ { "spapr-tpm-proxy", QEMU_CAPS_DEVICE_SPAPR_TPM_PROXY },
};
static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsVirtioBalloon[] = {
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index cdeaf09cce..92aca0470b 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -561,6 +561,7 @@ typedef enum { /* virQEMUCapsFlags grouping marker for syntax-check
*/
QEMU_CAPS_MACHINE_PSERIES_CAP_SBBC, /* -machine pseries.cap-sbbc */
QEMU_CAPS_MACHINE_PSERIES_CAP_IBS, /* -machine pseries.cap-ibs */
QEMU_CAPS_TCG, /* QEMU does support TCG */
+ QEMU_CAPS_DEVICE_SPAPR_TPM_PROXY, /* -device spapr-tpm-proxy */
QEMU_CAPS_LAST /* this must always be the last item */
} virQEMUCapsFlags;
diff --git a/tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml
b/tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml
index 796ed0a2bc..75301833e6 100644
--- a/tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml
+++ b/tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml
@@ -184,6 +184,7 @@
<flag name='machine.pseries.cap-sbbc'/>
<flag name='machine.pseries.cap-ibs'/>
<flag name='tcg'/>
+ <flag name='spapr-tpm-proxy'/>
<version>4001050</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>42900242</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml
b/tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml
index a5f0bb538b..08cf607cbf 100644
--- a/tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml
+++ b/tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml
@@ -199,6 +199,7 @@
<flag name='machine.pseries.cap-sbbc'/>
<flag name='machine.pseries.cap-ibs'/>
<flag name='tcg'/>
+ <flag name='spapr-tpm-proxy'/>
<version>5000000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>42900241</microcodeVersion>
--
2.26.2
5:48 p.m.
New subject: [PATCH v1 2/8] qemu: Extend QEMU capabilities with 'spapr-tpm-proxy'
On 5/8/20 8:06 AM, Daniel Henrique Barboza wrote:
Expose the TPM Proxy support for PPC64 guests by creating a new
cap called QEMU_CAPS_DEVICE_SPAPR_TPM_PROXY.
Signed-off-by: Daniel Henrique Barboza <danielhb413(a)gmail.com>
---
src/qemu/qemu_capabilities.c | 2 ++
src/qemu/qemu_capabilities.h | 1 +
tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 +
tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 +
4 files changed, 5 insertions(+)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 2c6e36685e..dcc1886954 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -580,6 +580,7 @@ VIR_ENUM_IMPL(virQEMUCaps,
"machine.pseries.cap-sbbc",
"machine.pseries.cap-ibs",
"tcg",
+ "spapr-tpm-proxy",
To me a proxy is something different and enablement of a
ultracall/hypercall type of thing. Call it spapr-tpm-hcall?
);
@@ -1301,6 +1302,7 @@ struct virQEMUCapsStringFlags virQEMUCapsObjectTypes[] = {
{ "tpm-spapr", QEMU_CAPS_DEVICE_TPM_SPAPR },
{ "vhost-user-fs-device", QEMU_CAPS_DEVICE_VHOST_USER_FS },
{ "tcg-accel", QEMU_CAPS_TCG },
+ { "spapr-tpm-proxy", QEMU_CAPS_DEVICE_SPAPR_TPM_PROXY },
};
static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsVirtioBalloon[] = {
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index cdeaf09cce..92aca0470b 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -561,6 +561,7 @@ typedef enum { /* virQEMUCapsFlags grouping marker for syntax-check
*/
QEMU_CAPS_MACHINE_PSERIES_CAP_SBBC, /* -machine pseries.cap-sbbc */
QEMU_CAPS_MACHINE_PSERIES_CAP_IBS, /* -machine pseries.cap-ibs */
QEMU_CAPS_TCG, /* QEMU does support TCG */
+ QEMU_CAPS_DEVICE_SPAPR_TPM_PROXY, /* -device spapr-tpm-proxy */
QEMU_CAPS_LAST /* this must always be the last item */
} virQEMUCapsFlags;
diff --git a/tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml
b/tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml
index 796ed0a2bc..75301833e6 100644
--- a/tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml
+++ b/tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml
@@ -184,6 +184,7 @@
<flag name='machine.pseries.cap-sbbc'/>
<flag name='machine.pseries.cap-ibs'/>
<flag name='tcg'/>
+ <flag name='spapr-tpm-proxy'/>
<version>4001050</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>42900242</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml
b/tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml
index a5f0bb538b..08cf607cbf 100644
--- a/tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml
+++ b/tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml
@@ -199,6 +199,7 @@
<flag name='machine.pseries.cap-sbbc'/>
<flag name='machine.pseries.cap-ibs'/>
<flag name='tcg'/>
+ <flag name='spapr-tpm-proxy'/>
<version>5000000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>42900241</microcodeVersion>
8:25 p.m.
New subject: [PATCH v1 2/8] qemu: Extend QEMU capabilities with 'spapr-tpm-proxy'
On Fri, May 08, 2020 at 06:48:24PM -0400, Stefan Berger wrote:
On 5/8/20 8:06 AM, Daniel Henrique Barboza wrote:
> Expose the TPM Proxy support for PPC64 guests by creating a new
> cap called QEMU_CAPS_DEVICE_SPAPR_TPM_PROXY.
>
> Signed-off-by: Daniel Henrique Barboza <danielhb413(a)gmail.com>
> ---
> src/qemu/qemu_capabilities.c | 2 ++
> src/qemu/qemu_capabilities.h | 1 +
> tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 +
> tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 +
> 4 files changed, 5 insertions(+)
>
> diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
> index 2c6e36685e..dcc1886954 100644
> --- a/src/qemu/qemu_capabilities.c
> +++ b/src/qemu/qemu_capabilities.c
> @@ -580,6 +580,7 @@ VIR_ENUM_IMPL(virQEMUCaps,
> "machine.pseries.cap-sbbc",
> "machine.pseries.cap-ibs",
> "tcg",
> + "spapr-tpm-proxy",
To me a proxy is something different and enablement of a ultracall/hypercall
type of thing. Call it spapr-tpm-hcall?
The "spapr-tpm-proxy" name is already exposed at the qemu level. And
while, I can agree that's maybe not a great name, I think it's
probably even more confusing to add another name fro it at the libvirt level.
> );
> @@ -1301,6 +1302,7 @@ struct virQEMUCapsStringFlags virQEMUCapsObjectTypes[] = {
> { "tpm-spapr", QEMU_CAPS_DEVICE_TPM_SPAPR },
> { "vhost-user-fs-device", QEMU_CAPS_DEVICE_VHOST_USER_FS },
> { "tcg-accel", QEMU_CAPS_TCG },
> + { "spapr-tpm-proxy", QEMU_CAPS_DEVICE_SPAPR_TPM_PROXY },
> };
> static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsVirtioBalloon[] = {
> diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
> index cdeaf09cce..92aca0470b 100644
> --- a/src/qemu/qemu_capabilities.h
> +++ b/src/qemu/qemu_capabilities.h
> @@ -561,6 +561,7 @@ typedef enum { /* virQEMUCapsFlags grouping marker for
syntax-check */
> QEMU_CAPS_MACHINE_PSERIES_CAP_SBBC, /* -machine pseries.cap-sbbc */
> QEMU_CAPS_MACHINE_PSERIES_CAP_IBS, /* -machine pseries.cap-ibs */
> QEMU_CAPS_TCG, /* QEMU does support TCG */
> + QEMU_CAPS_DEVICE_SPAPR_TPM_PROXY, /* -device spapr-tpm-proxy */
> QEMU_CAPS_LAST /* this must always be the last item */
> } virQEMUCapsFlags;
> diff --git a/tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml
b/tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml
> index 796ed0a2bc..75301833e6 100644
> --- a/tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml
> +++ b/tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml
> @@ -184,6 +184,7 @@
> <flag name='machine.pseries.cap-sbbc'/>
> <flag name='machine.pseries.cap-ibs'/>
> <flag name='tcg'/>
> + <flag name='spapr-tpm-proxy'/>
> <version>4001050</version>
> <kvmVersion>0</kvmVersion>
> <microcodeVersion>42900242</microcodeVersion>
> diff --git a/tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml
b/tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml
> index a5f0bb538b..08cf607cbf 100644
> --- a/tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml
> +++ b/tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml
> @@ -199,6 +199,7 @@
> <flag name='machine.pseries.cap-sbbc'/>
> <flag name='machine.pseries.cap-ibs'/>
> <flag name='tcg'/>
> + <flag name='spapr-tpm-proxy'/>
> <version>5000000</version>
> <kvmVersion>0</kvmVersion>
> <microcodeVersion>42900241</microcodeVersion>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
7:06 a.m.
New subject: [PATCH v1 3/8] conf, qemu: adding VIR_DOMAIN_DEVICE_TPMPROXY device
This new device will be used to represent a single instance of a
TPM Proxy for the domain.
XML functions to parse and format the device from the XML definition
will be added in the next patch.
Signed-off-by: Daniel Henrique Barboza <danielhb413(a)gmail.com>
---
src/conf/domain_capabilities.c | 1 +
src/conf/domain_conf.c | 68 ++++++++++++++++++++++++++++++++++
src/conf/domain_conf.h | 18 +++++++++
src/conf/virconftypes.h | 3 ++
src/qemu/qemu_command.c | 1 +
src/qemu/qemu_domain.c | 14 +++++++
src/qemu/qemu_domain_address.c | 2 +
src/qemu/qemu_driver.c | 5 +++
src/qemu/qemu_hotplug.c | 3 ++
src/qemu/qemu_validate.c | 37 ++++++++++++++++++
10 files changed, 152 insertions(+)
diff --git a/src/conf/domain_capabilities.c b/src/conf/domain_capabilities.c
index 921d795630..485fa9a22d 100644
--- a/src/conf/domain_capabilities.c
+++ b/src/conf/domain_capabilities.c
@@ -703,6 +703,7 @@ virDomainCapsDeviceDefValidate(const virDomainCaps *caps,
case VIR_DOMAIN_DEVICE_TPM:
case VIR_DOMAIN_DEVICE_PANIC:
case VIR_DOMAIN_DEVICE_IOMMU:
+ case VIR_DOMAIN_DEVICE_TPMPROXY:
case VIR_DOMAIN_DEVICE_NONE:
case VIR_DOMAIN_DEVICE_LAST:
break;
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 83748354b0..4c731b9f36 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -323,6 +323,7 @@ VIR_ENUM_IMPL(virDomainDevice,
"memory",
"iommu",
"vsock",
+ "tpmproxy",
);
VIR_ENUM_IMPL(virDomainDiskDevice,
@@ -1180,6 +1181,12 @@ VIR_ENUM_IMPL(virDomainTPMVersion,
"2.0",
);
+VIR_ENUM_IMPL(virDomainTPMProxyModel,
+ VIR_DOMAIN_TPMPROXY_MODEL_LAST,
+ "default",
+ "spapr-tpm-proxy",
+);
+
VIR_ENUM_IMPL(virDomainIOMMUModel,
VIR_DOMAIN_IOMMU_MODEL_LAST,
"intel",
@@ -3061,6 +3068,17 @@ void virDomainTPMDefFree(virDomainTPMDefPtr def)
VIR_FREE(def);
}
+void virDomainTPMProxyDefFree(virDomainTPMProxyDefPtr def)
+{
+ if (!def)
+ return;
+
+ VIR_FREE(def->path);
+ virDomainDeviceInfoClear(&def->info);
+ VIR_FREE(def);
+
+}
+
void virDomainHostdevDefFree(virDomainHostdevDefPtr def)
{
if (!def)
@@ -3187,6 +3205,9 @@ void virDomainDeviceDefFree(virDomainDeviceDefPtr def)
case VIR_DOMAIN_DEVICE_TPM:
virDomainTPMDefFree(def->data.tpm);
break;
+ case VIR_DOMAIN_DEVICE_TPMPROXY:
+ virDomainTPMProxyDefFree(def->data.tpmproxy);
+ break;
case VIR_DOMAIN_DEVICE_PANIC:
virDomainPanicDefFree(def->data.panic);
break;
@@ -3480,6 +3501,7 @@ void virDomainDefFree(virDomainDefPtr def)
VIR_FREE(def->mems);
virDomainTPMDefFree(def->tpm);
+ virDomainTPMProxyDefFree(def->tpmproxy);
for (i = 0; i < def->npanics; i++)
virDomainPanicDefFree(def->panics[i]);
@@ -4038,6 +4060,8 @@ virDomainDeviceGetInfo(virDomainDeviceDefPtr device)
return &device->data.memory->info;
case VIR_DOMAIN_DEVICE_VSOCK:
return &device->data.vsock->info;
+ case VIR_DOMAIN_DEVICE_TPMPROXY:
+ return &device->data.tpmproxy->info;
/* The following devices do not contain virDomainDeviceInfo */
case VIR_DOMAIN_DEVICE_LEASE:
@@ -4137,6 +4161,9 @@ virDomainDeviceSetData(virDomainDeviceDefPtr device,
case VIR_DOMAIN_DEVICE_LEASE:
device->data.lease = devicedata;
break;
+ case VIR_DOMAIN_DEVICE_TPMPROXY:
+ device->data.tpmproxy = devicedata;
+ break;
case VIR_DOMAIN_DEVICE_NONE:
case VIR_DOMAIN_DEVICE_LAST:
break;
@@ -4318,6 +4345,12 @@ virDomainDeviceInfoIterateInternal(virDomainDefPtr def,
if ((rc = cb(def, &device, &def->tpm->info, opaque)) != 0)
return rc;
}
+ if (def->tpmproxy) {
+ device.type = VIR_DOMAIN_DEVICE_TPMPROXY;
+ device.data.tpmproxy = def->tpmproxy;
+ if ((rc = cb(def, &device, &def->tpmproxy->info, opaque)) != 0)
+ return rc;
+ }
device.type = VIR_DOMAIN_DEVICE_PANIC;
for (i = 0; i < def->npanics; i++) {
device.data.panic = def->panics[i];
@@ -4403,6 +4436,7 @@ virDomainDeviceInfoIterateInternal(virDomainDefPtr def,
case VIR_DOMAIN_DEVICE_MEMORY:
case VIR_DOMAIN_DEVICE_IOMMU:
case VIR_DOMAIN_DEVICE_VSOCK:
+ case VIR_DOMAIN_DEVICE_TPMPROXY:
break;
}
#endif
@@ -5395,6 +5429,7 @@ virDomainDeviceDefPostParseCommon(virDomainDeviceDefPtr dev,
case VIR_DOMAIN_DEVICE_PANIC:
case VIR_DOMAIN_DEVICE_MEMORY:
case VIR_DOMAIN_DEVICE_IOMMU:
+ case VIR_DOMAIN_DEVICE_TPMPROXY:
ret = 0;
break;
@@ -6795,6 +6830,7 @@ virDomainDeviceDefValidateInternal(const virDomainDeviceDef *dev,
case VIR_DOMAIN_DEVICE_TPM:
case VIR_DOMAIN_DEVICE_PANIC:
case VIR_DOMAIN_DEVICE_IOMMU:
+ case VIR_DOMAIN_DEVICE_TPMPROXY:
case VIR_DOMAIN_DEVICE_NONE:
case VIR_DOMAIN_DEVICE_LAST:
break;
@@ -17039,6 +17075,7 @@ virDomainDeviceDefParse(const char *xmlStr,
flags)))
return NULL;
break;
+ case VIR_DOMAIN_DEVICE_TPMPROXY:
case VIR_DOMAIN_DEVICE_NONE:
case VIR_DOMAIN_DEVICE_LAST:
break;
@@ -23743,6 +23780,25 @@ virDomainTPMDefCheckABIStability(virDomainTPMDefPtr src,
}
+static bool
+virDomainTPMProxyDefCheckABIStability(virDomainTPMProxyDefPtr src,
+ virDomainTPMProxyDefPtr dst)
+{
+ if (src->model != dst->model) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("Target TPM Proxy device model doesn't match
source"));
+ return false;
+ }
+
+ if (STRNEQ_NULLABLE(src->path, dst->path)) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("Target TPM Proxy device path doesn't match
source"));
+ return false;
+ }
+
+ return virDomainDeviceInfoCheckABIStability(&src->info, &dst->info);
+}
+
static bool
virDomainMemtuneCheckABIStability(const virDomainDef *src,
const virDomainDef *dst,
@@ -24355,6 +24411,16 @@ virDomainDefCheckABIStabilityFlags(virDomainDefPtr src,
goto error;
}
+ if (src->tpmproxy && dst->tpmproxy) {
+ if (!virDomainTPMProxyDefCheckABIStability(src->tpmproxy, dst->tpmproxy))
+ goto error;
+ } else if (src->tpmproxy || dst->tpmproxy) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("Either both target and source domains or none of "
+ "them must have TPM Proxy device present"));
+ goto error;
+ }
+
if (src->nmems != dst->nmems) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("Target domain memory device count %zu "
@@ -24427,6 +24493,7 @@ virDomainDefCheckABIStabilityFlags(virDomainDefPtr src,
case VIR_DOMAIN_DEVICE_MEMORY:
case VIR_DOMAIN_DEVICE_IOMMU:
case VIR_DOMAIN_DEVICE_VSOCK:
+ case VIR_DOMAIN_DEVICE_TPMPROXY:
break;
}
#endif
@@ -30977,6 +31044,7 @@ virDomainDeviceDefCopy(virDomainDeviceDefPtr src,
case VIR_DOMAIN_DEVICE_MEMBALLOON:
case VIR_DOMAIN_DEVICE_NVRAM:
case VIR_DOMAIN_DEVICE_IOMMU:
+ case VIR_DOMAIN_DEVICE_TPMPROXY:
case VIR_DOMAIN_DEVICE_LAST:
virReportError(VIR_ERR_INTERNAL_ERROR,
_("Copying definition of '%d' type "
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 4afd8f04bc..d9b6bc5a22 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -85,6 +85,7 @@ typedef enum {
VIR_DOMAIN_DEVICE_MEMORY,
VIR_DOMAIN_DEVICE_IOMMU,
VIR_DOMAIN_DEVICE_VSOCK,
+ VIR_DOMAIN_DEVICE_TPMPROXY,
VIR_DOMAIN_DEVICE_LAST
} virDomainDeviceType;
@@ -116,6 +117,7 @@ struct _virDomainDeviceDef {
virDomainMemoryDefPtr memory;
virDomainIOMMUDefPtr iommu;
virDomainVsockDefPtr vsock;
+ virDomainTPMProxyDefPtr tpmproxy;
} data;
};
@@ -1330,6 +1332,19 @@ struct _virDomainTPMDef {
} data;
};
+typedef enum {
+ VIR_DOMAIN_TPMPROXY_MODEL_DEFAULT,
+ VIR_DOMAIN_TPMPROXY_MODEL_SPAPR,
+
+ VIR_DOMAIN_TPMPROXY_MODEL_LAST
+} virDomainTPMProxyModel;
+
+struct _virDomainTPMProxyDef {
+ virDomainDeviceInfo info;
+ int model; /* virDomainTPMProxyModel */
+ char *path;
+};
+
typedef enum {
VIR_DOMAIN_INPUT_TYPE_MOUSE,
VIR_DOMAIN_INPUT_TYPE_TABLET,
@@ -2625,6 +2640,7 @@ struct _virDomainDef {
virDomainMemballoonDefPtr memballoon;
virDomainNVRAMDefPtr nvram;
virDomainTPMDefPtr tpm;
+ virDomainTPMProxyDefPtr tpmproxy;
virCPUDefPtr cpu;
virSysinfoDefPtr sysinfo;
virDomainRedirFilterDefPtr redirfilter;
@@ -3023,6 +3039,7 @@ virDomainDeviceInfoPtr virDomainDeviceGetInfo(virDomainDeviceDefPtr
device);
void virDomainDeviceSetData(virDomainDeviceDefPtr device,
void *devicedata);
void virDomainTPMDefFree(virDomainTPMDefPtr def);
+void virDomainTPMProxyDefFree(virDomainTPMProxyDefPtr def);
typedef int (*virDomainDeviceInfoCallback)(virDomainDefPtr def,
virDomainDeviceDefPtr dev,
@@ -3594,6 +3611,7 @@ VIR_ENUM_DECL(virDomainRNGBackend);
VIR_ENUM_DECL(virDomainTPMModel);
VIR_ENUM_DECL(virDomainTPMBackend);
VIR_ENUM_DECL(virDomainTPMVersion);
+VIR_ENUM_DECL(virDomainTPMProxyModel);
VIR_ENUM_DECL(virDomainMemoryModel);
VIR_ENUM_DECL(virDomainMemoryBackingModel);
VIR_ENUM_DECL(virDomainMemorySource);
diff --git a/src/conf/virconftypes.h b/src/conf/virconftypes.h
index 1c62cde251..5c4a149f24 100644
--- a/src/conf/virconftypes.h
+++ b/src/conf/virconftypes.h
@@ -312,6 +312,9 @@ typedef virDomainSoundDef *virDomainSoundDefPtr;
typedef struct _virDomainTPMDef virDomainTPMDef;
typedef virDomainTPMDef *virDomainTPMDefPtr;
+typedef struct _virDomainTPMProxyDef virDomainTPMProxyDef;
+typedef virDomainTPMProxyDef *virDomainTPMProxyDefPtr;
+
typedef struct _virDomainThreadSchedParam virDomainThreadSchedParam;
typedef virDomainThreadSchedParam *virDomainThreadSchedParamPtr;
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 269bdbaf56..9065164b1d 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -537,6 +537,7 @@ qemuBuildVirtioDevStr(virBufferPtr buf,
case VIR_DOMAIN_DEVICE_PANIC:
case VIR_DOMAIN_DEVICE_MEMORY:
case VIR_DOMAIN_DEVICE_IOMMU:
+ case VIR_DOMAIN_DEVICE_TPMPROXY:
case VIR_DOMAIN_DEVICE_LAST:
default:
return 0;
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 9c629c31a3..3e86797093 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -5923,6 +5923,16 @@ qemuDomainTPMDefPostParse(virDomainTPMDefPtr tpm,
}
+static int
+qemuDomainTPMProxyDefPostParse(virDomainTPMProxyDefPtr tpmproxy)
+{
+ if (tpmproxy->model == VIR_DOMAIN_TPMPROXY_MODEL_DEFAULT)
+ tpmproxy->model = VIR_DOMAIN_TPMPROXY_MODEL_SPAPR;
+
+ return 0;
+}
+
+
static int
qemuDomainDeviceDefPostParse(virDomainDeviceDefPtr dev,
const virDomainDef *def,
@@ -5980,6 +5990,10 @@ qemuDomainDeviceDefPostParse(virDomainDeviceDefPtr dev,
ret = qemuDomainTPMDefPostParse(dev->data.tpm, def->os.arch);
break;
+ case VIR_DOMAIN_DEVICE_TPMPROXY:
+ ret = qemuDomainTPMProxyDefPostParse(dev->data.tpmproxy);
+ break;
+
case VIR_DOMAIN_DEVICE_LEASE:
case VIR_DOMAIN_DEVICE_FS:
case VIR_DOMAIN_DEVICE_INPUT:
diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index 07431343ed..566516f8b5 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -528,6 +528,7 @@ qemuDomainDeviceSupportZPCI(virDomainDeviceDefPtr device)
case VIR_DOMAIN_DEVICE_MEMORY:
case VIR_DOMAIN_DEVICE_IOMMU:
case VIR_DOMAIN_DEVICE_VSOCK:
+ case VIR_DOMAIN_DEVICE_TPMPROXY:
break;
case VIR_DOMAIN_DEVICE_NONE:
@@ -1031,6 +1032,7 @@ qemuDomainDeviceCalculatePCIConnectFlags(virDomainDeviceDefPtr dev,
case VIR_DOMAIN_DEVICE_HUB:
case VIR_DOMAIN_DEVICE_REDIRDEV:
case VIR_DOMAIN_DEVICE_SMARTCARD:
+ case VIR_DOMAIN_DEVICE_TPMPROXY:
/* These devices don't even have a DeviceInfo */
case VIR_DOMAIN_DEVICE_LEASE:
case VIR_DOMAIN_DEVICE_GRAPHICS:
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 1c7c87128d..57575b705f 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -7956,6 +7956,7 @@ qemuDomainAttachDeviceLive(virDomainObjPtr vm,
case VIR_DOMAIN_DEVICE_TPM:
case VIR_DOMAIN_DEVICE_PANIC:
case VIR_DOMAIN_DEVICE_IOMMU:
+ case VIR_DOMAIN_DEVICE_TPMPROXY:
case VIR_DOMAIN_DEVICE_LAST:
virReportError(VIR_ERR_OPERATION_UNSUPPORTED,
_("live attach of device '%s' is not
supported"),
@@ -8090,6 +8091,7 @@ qemuDomainUpdateDeviceLive(virDomainObjPtr vm,
case VIR_DOMAIN_DEVICE_PANIC:
case VIR_DOMAIN_DEVICE_IOMMU:
case VIR_DOMAIN_DEVICE_VSOCK:
+ case VIR_DOMAIN_DEVICE_TPMPROXY:
case VIR_DOMAIN_DEVICE_LAST:
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("live update of device '%s' is not
supported"),
@@ -8311,6 +8313,7 @@ qemuDomainAttachDeviceConfig(virDomainDefPtr vmdef,
case VIR_DOMAIN_DEVICE_TPM:
case VIR_DOMAIN_DEVICE_PANIC:
case VIR_DOMAIN_DEVICE_IOMMU:
+ case VIR_DOMAIN_DEVICE_TPMPROXY:
case VIR_DOMAIN_DEVICE_LAST:
virReportError(VIR_ERR_OPERATION_UNSUPPORTED,
_("persistent attach of device '%s' is not
supported"),
@@ -8513,6 +8516,7 @@ qemuDomainDetachDeviceConfig(virDomainDefPtr vmdef,
case VIR_DOMAIN_DEVICE_TPM:
case VIR_DOMAIN_DEVICE_PANIC:
case VIR_DOMAIN_DEVICE_IOMMU:
+ case VIR_DOMAIN_DEVICE_TPMPROXY:
case VIR_DOMAIN_DEVICE_LAST:
virReportError(VIR_ERR_OPERATION_UNSUPPORTED,
_("persistent detach of device '%s' is not
supported"),
@@ -8620,6 +8624,7 @@ qemuDomainUpdateDeviceConfig(virDomainDefPtr vmdef,
case VIR_DOMAIN_DEVICE_PANIC:
case VIR_DOMAIN_DEVICE_IOMMU:
case VIR_DOMAIN_DEVICE_VSOCK:
+ case VIR_DOMAIN_DEVICE_TPMPROXY:
case VIR_DOMAIN_DEVICE_LAST:
virReportError(VIR_ERR_OPERATION_UNSUPPORTED,
_("persistent update of device '%s' is not
supported"),
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index 60d0729f1e..aba80c87d3 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -4980,6 +4980,7 @@ qemuDomainRemoveAuditDevice(virDomainObjPtr vm,
case VIR_DOMAIN_DEVICE_TPM:
case VIR_DOMAIN_DEVICE_PANIC:
case VIR_DOMAIN_DEVICE_IOMMU:
+ case VIR_DOMAIN_DEVICE_TPMPROXY:
case VIR_DOMAIN_DEVICE_LAST:
/* libvirt doesn't yet support detaching these devices */
break;
@@ -5078,6 +5079,7 @@ qemuDomainRemoveDevice(virQEMUDriverPtr driver,
case VIR_DOMAIN_DEVICE_TPM:
case VIR_DOMAIN_DEVICE_PANIC:
case VIR_DOMAIN_DEVICE_IOMMU:
+ case VIR_DOMAIN_DEVICE_TPMPROXY:
case VIR_DOMAIN_DEVICE_LAST:
virReportError(VIR_ERR_OPERATION_UNSUPPORTED,
_("don't know how to remove a %s device"),
@@ -5849,6 +5851,7 @@ qemuDomainDetachDeviceLive(virDomainObjPtr vm,
case VIR_DOMAIN_DEVICE_TPM:
case VIR_DOMAIN_DEVICE_PANIC:
case VIR_DOMAIN_DEVICE_IOMMU:
+ case VIR_DOMAIN_DEVICE_TPMPROXY:
case VIR_DOMAIN_DEVICE_LAST:
virReportError(VIR_ERR_OPERATION_UNSUPPORTED,
_("live detach of device '%s' is not
supported"),
diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c
index 9debac6b30..733850416a 100644
--- a/src/qemu/qemu_validate.c
+++ b/src/qemu/qemu_validate.c
@@ -3326,6 +3326,38 @@ qemuValidateDomainDeviceDefTPM(virDomainTPMDef *tpm,
}
+static int
+qemuValidateDomainDeviceDefTPMProxy(virDomainTPMProxyDef *tpmproxy,
+ const virDomainDef *def,
+ virQEMUCapsPtr qemuCaps)
+{
+ if (!ARCH_IS_PPC64(def->os.arch)) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("TPM Proxy device is only supported "
+ "for PPC64 guests"));
+ return -1;
+ }
+
+ switch ((virDomainTPMProxyModel)tpmproxy->model) {
+ case VIR_DOMAIN_TPMPROXY_MODEL_DEFAULT:
+ case VIR_DOMAIN_TPMPROXY_MODEL_SPAPR:
+ if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_SPAPR_TPM_PROXY)) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("TPM Proxy is not supported "
+ "with this QEMU binary"));
+ return -1;
+ }
+ break;
+ case VIR_DOMAIN_TPMPROXY_MODEL_LAST:
+ default:
+ virReportEnumRangeError(virDomainTPMProxyModel,
+ tpmproxy->model);
+ return -1;
+ }
+
+ return 0;
+}
+
static int
qemuValidateDomainDeviceDefInput(const virDomainInputDef *input,
const virDomainDef *def,
@@ -3722,6 +3754,11 @@ qemuValidateDomainDeviceDef(const virDomainDeviceDef *dev,
ret = qemuValidateDomainDeviceDefMemory(dev->data.memory, qemuCaps);
break;
+ case VIR_DOMAIN_DEVICE_TPMPROXY:
+ ret = qemuValidateDomainDeviceDefTPMProxy(dev->data.tpmproxy,
+ def, qemuCaps);
+ break;
+
case VIR_DOMAIN_DEVICE_LEASE:
case VIR_DOMAIN_DEVICE_SHMEM:
case VIR_DOMAIN_DEVICE_PANIC:
--
2.26.2
7:06 a.m.
New subject: [PATCH v1 4/8] domain_conf.c: XML parsing for VIR_DOMAIN_DEVICE_TPMPROXY
Add virDomainTPMProxyDefParseXML() and virDomainTPMProxyDefFormat()
to handle the creating of the TPM Proxy device via its XML
description.
Signed-off-by: Daniel Henrique Barboza <danielhb413(a)gmail.com>
---
src/conf/domain_conf.c | 94 +++++++++++++++++++++++++++++++++++++++++-
1 file changed, 93 insertions(+), 1 deletion(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 4c731b9f36..4f43dcddee 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -13779,6 +13779,50 @@ virDomainTPMDefParseXML(virDomainXMLOptionPtr xmlopt,
return NULL;
}
+static virDomainTPMProxyDefPtr
+virDomainTPMProxyDefParseXML(virDomainXMLOptionPtr xmlopt,
+ xmlNodePtr node,
+ xmlXPathContextPtr ctxt,
+ unsigned int flags)
+{
+ virDomainTPMProxyDefPtr def;
+ VIR_XPATH_NODE_AUTORESTORE(ctxt);
+ g_autofree char *path = NULL;
+ g_autofree char *model = NULL;
+
+ if (VIR_ALLOC(def) < 0)
+ return NULL;
+
+ def->model = VIR_DOMAIN_TPMPROXY_MODEL_DEFAULT;
+
+ model = virXMLPropString(node, "model");
+ if (model != NULL &&
+ (def->model = virDomainTPMProxyModelTypeFromString(model)) < 0) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+ _("Unknown TPM Proxy frontend model '%s'"),
model);
+ goto error;
+ }
+
+ ctxt->node = node;
+
+ path = virXPathString("string(./device/@path)", ctxt);
+ if (!path) {
+ virReportError(VIR_ERR_XML_ERROR, "%s",
+ _("missing TPM Proxy device path"));
+ goto error;
+ }
+ def->path = g_steal_pointer(&path);
+
+ if (virDomainDeviceInfoParseXML(xmlopt, node, &def->info, flags) < 0)
+ goto error;
+
+ return def;
+
+ error:
+ virDomainTPMProxyDefFree(def);
+ return NULL;
+}
+
static virDomainPanicDefPtr
virDomainPanicDefParseXML(virDomainXMLOptionPtr xmlopt,
xmlNodePtr node,
@@ -17076,6 +17120,10 @@ virDomainDeviceDefParse(const char *xmlStr,
return NULL;
break;
case VIR_DOMAIN_DEVICE_TPMPROXY:
+ if (!(dev->data.tpmproxy = virDomainTPMProxyDefParseXML(xmlopt, node,
+ ctxt, flags)))
+ return NULL;
+ break;
case VIR_DOMAIN_DEVICE_NONE:
case VIR_DOMAIN_DEVICE_LAST:
break;
@@ -22024,6 +22072,23 @@ virDomainDefParseXML(xmlDocPtr xml,
}
VIR_FREE(nodes);
+ /* Parse TPM Proxy device */
+ if ((n = virXPathNodeSet("./devices/tpmproxy", ctxt, &nodes)) < 0)
+ goto error;
+
+ if (n > 1) {
+ virReportError(VIR_ERR_XML_ERROR, "%s",
+ _("only a single TPM Proxy device is supported"));
+ goto error;
+ }
+
+ if (n > 0) {
+ if (!(def->tpmproxy = virDomainTPMProxyDefParseXML(xmlopt, nodes[0],
+ ctxt, flags)))
+ goto error;
+ }
+ VIR_FREE(nodes);
+
if ((n = virXPathNodeSet("./devices/nvram", ctxt, &nodes)) < 0)
goto error;
@@ -27166,6 +27231,26 @@ virDomainTPMDefFormat(virBufferPtr buf,
}
+static int
+virDomainTPMProxyDefFormat(virBufferPtr buf,
+ virDomainTPMProxyDefPtr def,
+ unsigned int flags)
+{
+ virBufferAsprintf(buf, "<tpmproxy model='%s'>\n",
+ virDomainTPMProxyModelTypeToString(def->model));
+ virBufferAdjustIndent(buf, 2);
+ virBufferEscapeString(buf, "<device path='%s'/>\n",
def->path);
+
+ if (virDomainDeviceInfoFormat(buf, &def->info, flags) < 0)
+ return -1;
+
+ virBufferAdjustIndent(buf, -2);
+ virBufferAddLit(buf, "</tpmproxy>\n");
+
+ return 0;
+}
+
+
static int
virDomainSoundDefFormat(virBufferPtr buf,
virDomainSoundDefPtr def,
@@ -29853,6 +29938,11 @@ virDomainDefFormatInternalSetRootName(virDomainDefPtr def,
goto error;
}
+ if (def->tpmproxy) {
+ if (virDomainTPMProxyDefFormat(buf, def->tpmproxy, flags) < 0)
+ goto error;
+ }
+
for (n = 0; n < def->ngraphics; n++) {
if (virDomainGraphicsDefFormat(buf, def->graphics[n], flags) < 0)
goto error;
@@ -31038,13 +31128,15 @@ virDomainDeviceDefCopy(virDomainDeviceDefPtr src,
case VIR_DOMAIN_DEVICE_VSOCK:
rc = virDomainVsockDefFormat(&buf, src->data.vsock);
break;
+ case VIR_DOMAIN_DEVICE_TPMPROXY:
+ rc = virDomainTPMProxyDefFormat(&buf, src->data.tpmproxy, flags);
+ break;
case VIR_DOMAIN_DEVICE_NONE:
case VIR_DOMAIN_DEVICE_SMARTCARD:
case VIR_DOMAIN_DEVICE_MEMBALLOON:
case VIR_DOMAIN_DEVICE_NVRAM:
case VIR_DOMAIN_DEVICE_IOMMU:
- case VIR_DOMAIN_DEVICE_TPMPROXY:
case VIR_DOMAIN_DEVICE_LAST:
virReportError(VIR_ERR_INTERNAL_ERROR,
_("Copying definition of '%d' type "
--
2.26.2
7:06 a.m.
New subject: [PATCH v1 5/8] tests: add test for domain XML with TPM Proxy device model
Update qemuxml2xmltest.c to add tests to validate the XML parsing
of the new TPM Proxy device type.
Signed-off-by: Daniel Henrique Barboza <danielhb413(a)gmail.com>
---
tests/qemuxml2argvdata/ppc64-tpmproxy.xml | 31 +++++++++++++++++
tests/qemuxml2xmloutdata/ppc64-tpmproxy.xml | 37 +++++++++++++++++++++
tests/qemuxml2xmltest.c | 4 +++
3 files changed, 72 insertions(+)
create mode 100644 tests/qemuxml2argvdata/ppc64-tpmproxy.xml
create mode 100644 tests/qemuxml2xmloutdata/ppc64-tpmproxy.xml
diff --git a/tests/qemuxml2argvdata/ppc64-tpmproxy.xml
b/tests/qemuxml2argvdata/ppc64-tpmproxy.xml
new file mode 100644
index 0000000000..fef82bd5c7
--- /dev/null
+++ b/tests/qemuxml2argvdata/ppc64-tpmproxy.xml
@@ -0,0 +1,31 @@
+<domain type='qemu'>
+ <name>QEMUGuest1</name>
+ <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
+ <memory unit='KiB'>219100</memory>
+ <currentMemory unit='KiB'>219100</currentMemory>
+ <vcpu placement='static'>1</vcpu>
+ <os>
+ <type arch='ppc64' machine='pseries'>hvm</type>
+ </os>
+ <features>
+ <acpi/>
+ <apic/>
+ <pae/>
+ </features>
+ <clock offset='utc'/>
+ <on_poweroff>destroy</on_poweroff>
+ <on_reboot>restart</on_reboot>
+ <on_crash>restart</on_crash>
+ <devices>
+ <emulator>/usr/bin/qemu-system-ppc64</emulator>
+ <controller type='usb' index='0'>
+ <address type='pci' domain='0x0000' bus='0x00'
slot='0x01' function='0x0'/>
+ </controller>
+ <tpmproxy>
+ <device path='/dev/tpmrm0'/>
+ </tpmproxy>
+ <memballoon model='virtio'>
+ <address type='pci' domain='0x0000' bus='0x00'
slot='0x06' function='0x0'/>
+ </memballoon>
+ </devices>
+</domain>
diff --git a/tests/qemuxml2xmloutdata/ppc64-tpmproxy.xml
b/tests/qemuxml2xmloutdata/ppc64-tpmproxy.xml
new file mode 100644
index 0000000000..9ad1da9434
--- /dev/null
+++ b/tests/qemuxml2xmloutdata/ppc64-tpmproxy.xml
@@ -0,0 +1,37 @@
+<domain type='qemu'>
+ <name>QEMUGuest1</name>
+ <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
+ <memory unit='KiB'>219100</memory>
+ <currentMemory unit='KiB'>219100</currentMemory>
+ <vcpu placement='static'>1</vcpu>
+ <os>
+ <type arch='ppc64' machine='pseries'>hvm</type>
+ <boot dev='hd'/>
+ </os>
+ <features>
+ <acpi/>
+ <apic/>
+ <pae/>
+ </features>
+ <clock offset='utc'/>
+ <on_poweroff>destroy</on_poweroff>
+ <on_reboot>restart</on_reboot>
+ <on_crash>restart</on_crash>
+ <devices>
+ <emulator>/usr/bin/qemu-system-ppc64</emulator>
+ <controller type='usb' index='0' model='pci-ohci'>
+ <address type='pci' domain='0x0000' bus='0x00'
slot='0x01' function='0x0'/>
+ </controller>
+ <controller type='pci' index='0' model='pci-root'>
+ <model name='spapr-pci-host-bridge'/>
+ <target index='0'/>
+ </controller>
+ <tpmproxy model='spapr-tpm-proxy'>
+ <device path='/dev/tpmrm0'/>
+ </tpmproxy>
+ <memballoon model='virtio'>
+ <address type='pci' domain='0x0000' bus='0x00'
slot='0x06' function='0x0'/>
+ </memballoon>
+ <panic model='pseries'/>
+ </devices>
+</domain>
diff --git a/tests/qemuxml2xmltest.c b/tests/qemuxml2xmltest.c
index 86f3d2c1f3..c9745ae337 100644
--- a/tests/qemuxml2xmltest.c
+++ b/tests/qemuxml2xmltest.c
@@ -610,6 +610,10 @@ mymain(void)
DO_TEST("controller-usb-order",
QEMU_CAPS_PIIX_DISABLE_S3,
QEMU_CAPS_PIIX_DISABLE_S4);
+ DO_TEST("ppc64-tpmproxy",
+ QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE,
+ QEMU_CAPS_PCI_OHCI,
+ QEMU_CAPS_DEVICE_SPAPR_TPM_PROXY);
DO_TEST_FULL("seclabel-dynamic-baselabel", WHEN_INACTIVE,
ARG_QEMU_CAPS, NONE);
--
2.26.2
7:06 a.m.
New subject: [PATCH v1 6/8] qemu: build command line for the TPM Proxy device
This patch wraps it up all the wiring done in previous patches,
enabling a PPC64 guest to launch a guest using a TPM Proxy
device.
Note that device validation is already being done in
qemu_validate.c, qemuValidateDomainDeviceDefTPMProxy(), on
domain define time. We don't need to verify QEMU capabilities for
this device again in qemu_command.c
Signed-off-by: Daniel Henrique Barboza <danielhb413(a)gmail.com>
---
src/libvirt_private.syms | 2 ++
src/qemu/qemu_alias.c | 16 ++++++++++++++++
src/qemu/qemu_command.c | 20 ++++++++++++++++++++
3 files changed, 38 insertions(+)
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 935ef7303b..b242c6164e 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -636,6 +636,8 @@ virDomainTPMBackendTypeToString;
virDomainTPMDefFree;
virDomainTPMModelTypeFromString;
virDomainTPMModelTypeToString;
+virDomainTPMProxyModelTypeFromString;
+virDomainTPMProxyModelTypeToString;
virDomainUSBDeviceDefForeach;
virDomainVideoDefaultRAM;
virDomainVideoDefClear;
diff --git a/src/qemu/qemu_alias.c b/src/qemu/qemu_alias.c
index b0ea62af39..b21d5bb514 100644
--- a/src/qemu/qemu_alias.c
+++ b/src/qemu/qemu_alias.c
@@ -413,6 +413,18 @@ qemuAssignDeviceTPMAlias(virDomainTPMDefPtr tpm,
}
+static int
+qemuAssignDeviceTPMProxyAlias(virDomainTPMProxyDefPtr tpmproxy,
+ int idx)
+{
+ if (tpmproxy->info.alias)
+ return 0;
+
+ tpmproxy->info.alias = g_strdup_printf("tpmproxy%d", idx);
+ return 0;
+}
+
+
int
qemuAssignDeviceRedirdevAlias(virDomainDefPtr def,
virDomainRedirdevDefPtr redirdev,
@@ -673,6 +685,10 @@ qemuAssignDeviceAliases(virDomainDefPtr def, virQEMUCapsPtr
qemuCaps)
if (qemuAssignDeviceTPMAlias(def->tpm, 0) < 0)
return -1;
}
+ if (def->tpmproxy) {
+ if (qemuAssignDeviceTPMProxyAlias(def->tpmproxy, 0) < 0)
+ return -1;
+ }
for (i = 0; i < def->nmems; i++) {
if (qemuAssignDeviceMemoryAlias(NULL, def->mems[i], false) < 0)
return -1;
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 9065164b1d..40a8505d24 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -9318,6 +9318,23 @@ qemuBuildTPMCommandLine(virCommandPtr cmd,
return 0;
}
+static int
+qemuBuildTPMProxyCommandLine(virCommandPtr cmd,
+ const virDomainDef *def)
+{
+ const virDomainTPMProxyDef *tpmproxy = def->tpmproxy;
+
+ if (!tpmproxy)
+ return 0;
+
+ virCommandAddArg(cmd, "-device");
+ virCommandAddArgFormat(cmd, "%s,id=%s,host-path=%s",
+ virDomainTPMProxyModelTypeToString(tpmproxy->model),
+ tpmproxy->info.alias, tpmproxy->path);
+
+ return 0;
+}
+
static int
qemuBuildSEVCommandLine(virDomainObjPtr vm, virCommandPtr cmd,
virDomainSEVDefPtr sev)
@@ -9999,6 +10016,9 @@ qemuBuildCommandLine(virQEMUDriverPtr driver,
if (qemuBuildTPMCommandLine(cmd, def, qemuCaps) < 0)
return NULL;
+ if (qemuBuildTPMProxyCommandLine(cmd, def) < 0)
+ return NULL;
+
if (qemuBuildInputCommandLine(cmd, def, qemuCaps) < 0)
return NULL;
--
2.26.2
7:06 a.m.
New subject: [PATCH v1 7/8] tests/qemuxml2argvtest.c: add TPM Proxy command line test
Add a new test to assert the QEMU command line being built
for the TPM Proxy device.
Signed-off-by: Daniel Henrique Barboza <danielhb413(a)gmail.com>
---
tests/qemuxml2argvdata/ppc64-tpmproxy.args | 28 ++++++++++++++++++++++
tests/qemuxml2argvtest.c | 4 ++++
2 files changed, 32 insertions(+)
create mode 100644 tests/qemuxml2argvdata/ppc64-tpmproxy.args
diff --git a/tests/qemuxml2argvdata/ppc64-tpmproxy.args
b/tests/qemuxml2argvdata/ppc64-tpmproxy.args
new file mode 100644
index 0000000000..a296a962ce
--- /dev/null
+++ b/tests/qemuxml2argvdata/ppc64-tpmproxy.args
@@ -0,0 +1,28 @@
+LC_ALL=C \
+PATH=/bin \
+HOME=/tmp/lib/domain--1-QEMUGuest1 \
+USER=test \
+LOGNAME=test \
+XDG_DATA_HOME=/tmp/lib/domain--1-QEMUGuest1/.local/share \
+XDG_CACHE_HOME=/tmp/lib/domain--1-QEMUGuest1/.cache \
+XDG_CONFIG_HOME=/tmp/lib/domain--1-QEMUGuest1/.config \
+QEMU_AUDIO_DRV=none \
+/usr/bin/qemu-system-ppc64 \
+-name QEMUGuest1 \
+-S \
+-machine pseries,accel=tcg,usb=off,dump-guest-core=off \
+-m 256 \
+-realtime mlock=off \
+-smp 1,sockets=1,cores=1,threads=1 \
+-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \
+-display none \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,path=/tmp/lib/domain--1-QEMUGuest1/monitor.sock,\
+server,nowait \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-device pci-ohci,id=usb,bus=pci.0,addr=0x1 \
+-device spapr-tpm-proxy,id=tpmproxy0,host-path=/dev/tpmrm0 \
+-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index 04febd1b0c..1a9b197907 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -2967,6 +2967,10 @@ mymain(void)
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE,
QEMU_CAPS_NEC_USB_XHCI,
QEMU_CAPS_DEVICE_QEMU_XHCI);
+ DO_TEST("ppc64-tpmproxy",
+ QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE,
+ QEMU_CAPS_PCI_OHCI,
+ QEMU_CAPS_DEVICE_SPAPR_TPM_PROXY);
DO_TEST("aarch64-usb-controller-qemu-xhci",
QEMU_CAPS_OBJECT_GPEX,
--
2.26.2
7:06 a.m.
New subject: [PATCH v1 8/8] docs/news.xml: update for the new TPM Proxy device
Signed-off-by: Daniel Henrique Barboza <danielhb413(a)gmail.com>
---
docs/news.xml | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/docs/news.xml b/docs/news.xml
index 4cef804aac..21ee98c45b 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -44,6 +44,20 @@
<libvirt>
<release version="v6.4.0" date="unreleased">
<section title="New features">
+ <change>
+ <summary>
+ qemu: add TPM Proxy device support
+ </summary>
+ <description>
+ libvirt can now create guests using a new device type called
+ "TPM Proxy". This new device type connects with a TPM Resource
+ Manager in the host, which allows multiple processes to access
+ TPM features concurrently. Only one TPM Proxy is allowed per
+ guest. A guest using a TPM Proxy device can instantiate a vTPM
+ device at the same time. This device is supported only for pSeries
+ guests via the 'spapr-tpm-proxy' virtual device.
+ </description>
+ </change>
</section>
<section title="Improvements">
</section>
--
2.26.2
3:18 p.m.
On 5/8/20 8:06 AM, Daniel Henrique Barboza wrote:
Hello,
This series implements a new device type for Libvirt called
"TPM Proxy". This device acts as a proxy for TPM requisitions
that the guest can make for an existing TPM Resource Manager
in the host. The TPM Resource Manager multiplexes TPM access
to multiple processes, allowing more than one process (guest)
to use the host TPM at the same time.
A guest using a TPM Proxy device does not have access to all
possible TPM features. In that case the guest will need to
'... does not have access to all possible TPM features': Is this device
filtering? Since I never used this device, I am wondering what does this
mean? What is the usage model of this device and in what case do you
intend to use it?
Do you give any guest now access to the host HW TPM and its PCRs and let
the guest extend them? That's not something you would want, at least not
for untrusted guests... keeping the device busy creating keys or loading
it up with keys is another possible issue.
assign a vTPM device (tpm-spapr for PPC64). There is no restrictions
of using both a vTPM and a TPM Proxy device at the same time,
but only one TPM Proxy is allowed per guest.
At this moment, this device exists only for QEMU pSeries guests.
A "model" field was added device to allow more models to be added
when/if other architectures implements it.
Daniel Henrique Barboza (8):
docs: documentation and schema for the new TPM Proxy device
qemu: Extend QEMU capabilities with 'spapr-tpm-proxy'
conf, qemu: adding VIR_DOMAIN_DEVICE_TPMPROXY device
domain_conf.c: XML parsing for VIR_DOMAIN_DEVICE_TPMPROXY
tests: add test for domain XML with TPM Proxy device model
qemu: build command line for the TPM Proxy device
tests/qemuxml2argvtest.c: add TPM Proxy command line test
docs/news.xml: update for the new TPM Proxy device
docs/formatdomain.html.in | 42 +++++
docs/news.xml | 14 ++
docs/schemas/domaincommon.rng | 18 ++
src/conf/domain_capabilities.c | 1 +
src/conf/domain_conf.c | 160 ++++++++++++++++++
src/conf/domain_conf.h | 18 ++
src/conf/virconftypes.h | 3 +
src/libvirt_private.syms | 2 +
src/qemu/qemu_alias.c | 16 ++
src/qemu/qemu_capabilities.c | 2 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 21 +++
src/qemu/qemu_domain.c | 14 ++
src/qemu/qemu_domain_address.c | 2 +
src/qemu/qemu_driver.c | 5 +
src/qemu/qemu_hotplug.c | 3 +
src/qemu/qemu_validate.c | 37 ++++
.../qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 +
.../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 +
tests/qemuxml2argvdata/ppc64-tpmproxy.args | 28 +++
tests/qemuxml2argvdata/ppc64-tpmproxy.xml | 31 ++++
tests/qemuxml2argvtest.c | 4 +
tests/qemuxml2xmloutdata/ppc64-tpmproxy.xml | 37 ++++
tests/qemuxml2xmltest.c | 4 +
24 files changed, 465 insertions(+)
create mode 100644 tests/qemuxml2argvdata/ppc64-tpmproxy.args
create mode 100644 tests/qemuxml2argvdata/ppc64-tpmproxy.xml
create mode 100644 tests/qemuxml2xmloutdata/ppc64-tpmproxy.xml
4:39 p.m.
(CCing Mike Roth since he implemented the QEMU support for this device)
On 5/8/20 5:18 PM, Stefan Berger wrote:
On 5/8/20 8:06 AM, Daniel Henrique Barboza wrote:
> Hello,
>
> This series implements a new device type for Libvirt called
> "TPM Proxy". This device acts as a proxy for TPM requisitions
> that the guest can make for an existing TPM Resource Manager
> in the host. The TPM Resource Manager multiplexes TPM access
> to multiple processes, allowing more than one process (guest)
> to use the host TPM at the same time.
>
> A guest using a TPM Proxy device does not have access to all
> possible TPM features. In that case the guest will need to
'... does not have access to all possible TPM features': Is this device
filtering? Since I never used this device, I am wondering what does this mean? What is the
usage model of this device and in what case do you intend to use it?
Do you give any guest now access to the host HW TPM and its PCRs and let the guest extend
them? That's not something you would want, at least not for untrusted guests...
keeping the device busy creating keys or loading it up with keys is another possible
issue.
This device is part of the machinery the guest need to orchestrate with the PPC64
Ultravisor the transition to the Secure VM (SVM) mode. Inside QEMU, the
'host-path' provided in this device will be used with the following hypercall:
- H_TPM_COMM (0xef10)
For TPM_COMM_OP_EXECUTE operation:
Send a request to a TPM and receive a response, opening a new TPM session
if one has not already been opened.
For TPM_COMM_OP_CLOSE_SESSION operation:
Close the existing TPM session, if any.
This was extracted from docs/specs/ppc-spapr-uv-hcalls.txt in QEMU tree. This
document also has a use case notes for this specific hypercall and how it
interacts with the TPM Resource Manager:
----
Use-case/notes:
SVM filesystems are encrypted using a symmetric key. This key is then
wrapped/encrypted using the public key of a trusted system which has the
private key stored in the system's TPM. An Ultravisor will use this
hcall to unwrap/unseal the symmetric key using the system's TPM device
or a TPM Resource Manager associated with the device.
The Ultravisor sets up a separate session key with the TPM in advance
during host system boot. All sensitive in and out values will be
encrypted using the session key. Though the hypervisor will see the 'in'
and 'out' buffers in raw form, any sensitive contents will generally be
encrypted using this session key.
----
I am not aware of any other use case for this device, aside from helping enable
SVM mode for PPC64 guests in coordination with an Ultravisor. Hope this clarifies
a bit what role the TPM Proxy/spapr-tpm-proxy plays out.
All this said, I made the decision to not treat it as a new type of the regular
vTPM device in Libvirt, given that there is no restriction of a guest using both
devices at the same time and the TPM Proxy plays a different role than vTPM. If we
decide that allowing both devices is a bad idea then we can limit the guest to
use either one or the other. In that case, we can discuss whether it makes sense
to change the logic in this series to make spapr-tpm-proxy another TPM passthrough
model like tpm-spapr, instead of creating a new device type.
Thanks,
DHB
> assign a vTPM device (tpm-spapr for PPC64). There is no restrictions
> of using both a vTPM and a TPM Proxy device at the same time,
> but only one TPM Proxy is allowed per guest.
>
> At this moment, this device exists only for QEMU pSeries guests.
> A "model" field was added device to allow more models to be added
> when/if other architectures implements it.
>
>
> Daniel Henrique Barboza (8):
> docs: documentation and schema for the new TPM Proxy device
> qemu: Extend QEMU capabilities with 'spapr-tpm-proxy'
> conf, qemu: adding VIR_DOMAIN_DEVICE_TPMPROXY device
> domain_conf.c: XML parsing for VIR_DOMAIN_DEVICE_TPMPROXY
> tests: add test for domain XML with TPM Proxy device model
> qemu: build command line for the TPM Proxy device
> tests/qemuxml2argvtest.c: add TPM Proxy command line test
> docs/news.xml: update for the new TPM Proxy device
>
> docs/formatdomain.html.in | 42 +++++
> docs/news.xml | 14 ++
> docs/schemas/domaincommon.rng | 18 ++
> src/conf/domain_capabilities.c | 1 +
> src/conf/domain_conf.c | 160 ++++++++++++++++++
> src/conf/domain_conf.h | 18 ++
> src/conf/virconftypes.h | 3 +
> src/libvirt_private.syms | 2 +
> src/qemu/qemu_alias.c | 16 ++
> src/qemu/qemu_capabilities.c | 2 +
> src/qemu/qemu_capabilities.h | 1 +
> src/qemu/qemu_command.c | 21 +++
> src/qemu/qemu_domain.c | 14 ++
> src/qemu/qemu_domain_address.c | 2 +
> src/qemu/qemu_driver.c | 5 +
> src/qemu/qemu_hotplug.c | 3 +
> src/qemu/qemu_validate.c | 37 ++++
> .../qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 +
> .../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 +
> tests/qemuxml2argvdata/ppc64-tpmproxy.args | 28 +++
> tests/qemuxml2argvdata/ppc64-tpmproxy.xml | 31 ++++
> tests/qemuxml2argvtest.c | 4 +
> tests/qemuxml2xmloutdata/ppc64-tpmproxy.xml | 37 ++++
> tests/qemuxml2xmltest.c | 4 +
> 24 files changed, 465 insertions(+)
> create mode 100644 tests/qemuxml2argvdata/ppc64-tpmproxy.args
> create mode 100644 tests/qemuxml2argvdata/ppc64-tpmproxy.xml
> create mode 100644 tests/qemuxml2xmloutdata/ppc64-tpmproxy.xml
>
5:39 p.m.
On 5/8/20 5:39 PM, Daniel Henrique Barboza wrote:
(CCing Mike Roth since he implemented the QEMU support for this
device)
On 5/8/20 5:18 PM, Stefan Berger wrote:
> On 5/8/20 8:06 AM, Daniel Henrique Barboza wrote:
>> Hello,
>>
>> This series implements a new device type for Libvirt called
>> "TPM Proxy". This device acts as a proxy for TPM requisitions
>> that the guest can make for an existing TPM Resource Manager
>> in the host. The TPM Resource Manager multiplexes TPM access
>> to multiple processes, allowing more than one process (guest)
>> to use the host TPM at the same time.
>>
>> A guest using a TPM Proxy device does not have access to all
>> possible TPM features. In that case the guest will need to
>
> '... does not have access to all possible TPM features': Is this
> device filtering? Since I never used this device, I am wondering what
> does this mean? What is the usage model of this device and in what
> case do you intend to use it?
>
> Do you give any guest now access to the host HW TPM and its PCRs and
> let the guest extend them? That's not something you would want, at
> least not for untrusted guests... keeping the device busy creating
> keys or loading it up with keys is another possible issue.
This device is part of the machinery the guest need to orchestrate
with the PPC64
Ultravisor the transition to the Secure VM (SVM) mode. Inside QEMU, the
'host-path' provided in this device will be used with the following
hypercall:
- H_TPM_COMM (0xef10)
For TPM_COMM_OP_EXECUTE operation:
Send a request to a TPM and receive a response, opening a new TPM
session
if one has not already been opened.
For TPM_COMM_OP_CLOSE_SESSION operation:
Close the existing TPM session, if any.
This was extracted from docs/specs/ppc-spapr-uv-hcalls.txt in QEMU
tree. This
document also has a use case notes for this specific hypercall and how it
interacts with the TPM Resource Manager:
----
Use-case/notes:
SVM filesystems are encrypted using a symmetric key. This key is then
wrapped/encrypted using the public key of a trusted system which
has the
private key stored in the system's TPM. An Ultravisor will use this
hcall to unwrap/unseal the symmetric key using the system's TPM
device
or a TPM Resource Manager associated with the device.
The Ultravisor sets up a separate session key with the TPM in advance
during host system boot. All sensitive in and out values will be
encrypted using the session key. Though the hypervisor will see
the 'in'
and 'out' buffers in raw form, any sensitive contents will
generally be
encrypted using this session key.
----
I am not aware of any other use case for this device, aside from
helping enable
SVM mode for PPC64 guests in coordination with an Ultravisor. Hope
this clarifies
a bit what role the TPM Proxy/spapr-tpm-proxy plays out.
All this said, I made the decision to not treat it as a new type of
the regular
vTPM device in Libvirt, given that there is no restriction of a guest
using both
devices at the same time and the TPM Proxy plays a different role than
vTPM. If we
decide that allowing both devices is a bad idea then we can limit the
guest to
use either one or the other. In that case, we can discuss whether it
makes sense
to change the logic in this series to make spapr-tpm-proxy another TPM
passthrough
model like tpm-spapr, instead of creating a new device type.
No I think both should be accessible. H_COMM_TPM would only be used at
the start of the secure VM, right? It should probably shut down once
it's not needed anymore so it cannot be abused by anything that happens
to want to abuse H_COMM_TPM , like a malicious driver in Linux or so if
that could be implemented. But that's obviously not something to worry
about on the libvirt level, but I didn't understand what this devices
exposes.
I looked over the patches. They look good to me on first glance.
Stefan
Thanks,
DHB
>
>
>> assign a vTPM device (tpm-spapr for PPC64). There is no restrictions
>> of using both a vTPM and a TPM Proxy device at the same time,
>> but only one TPM Proxy is allowed per guest.
>>
>> At this moment, this device exists only for QEMU pSeries guests.
>> A "model" field was added device to allow more models to be added
>> when/if other architectures implements it.
>>
>>
>> Daniel Henrique Barboza (8):
>> docs: documentation and schema for the new TPM Proxy device
>> qemu: Extend QEMU capabilities with 'spapr-tpm-proxy'
>> conf, qemu: adding VIR_DOMAIN_DEVICE_TPMPROXY device
>> domain_conf.c: XML parsing for VIR_DOMAIN_DEVICE_TPMPROXY
>> tests: add test for domain XML with TPM Proxy device model
>> qemu: build command line for the TPM Proxy device
>> tests/qemuxml2argvtest.c: add TPM Proxy command line test
>> docs/news.xml: update for the new TPM Proxy device
>>
>> docs/formatdomain.html.in | 42 +++++
>> docs/news.xml | 14 ++
>> docs/schemas/domaincommon.rng | 18 ++
>> src/conf/domain_capabilities.c | 1 +
>> src/conf/domain_conf.c | 160
>> ++++++++++++++++++
>> src/conf/domain_conf.h | 18 ++
>> src/conf/virconftypes.h | 3 +
>> src/libvirt_private.syms | 2 +
>> src/qemu/qemu_alias.c | 16 ++
>> src/qemu/qemu_capabilities.c | 2 +
>> src/qemu/qemu_capabilities.h | 1 +
>> src/qemu/qemu_command.c | 21 +++
>> src/qemu/qemu_domain.c | 14 ++
>> src/qemu/qemu_domain_address.c | 2 +
>> src/qemu/qemu_driver.c | 5 +
>> src/qemu/qemu_hotplug.c | 3 +
>> src/qemu/qemu_validate.c | 37 ++++
>> .../qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 +
>> .../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 +
>> tests/qemuxml2argvdata/ppc64-tpmproxy.args | 28 +++
>> tests/qemuxml2argvdata/ppc64-tpmproxy.xml | 31 ++++
>> tests/qemuxml2argvtest.c | 4 +
>> tests/qemuxml2xmloutdata/ppc64-tpmproxy.xml | 37 ++++
>> tests/qemuxml2xmltest.c | 4 +
>> 24 files changed, 465 insertions(+)
>> create mode 100644 tests/qemuxml2argvdata/ppc64-tpmproxy.args
>> create mode 100644 tests/qemuxml2argvdata/ppc64-tpmproxy.xml
>> create mode 100644 tests/qemuxml2xmloutdata/ppc64-tpmproxy.xml
>>
>
1654
days inactive
1659
days old
30 comments
4 participants
participants (4)
-
Daniel Henrique Barboza -
Daniel P. Berrangé -
David Gibson -
Stefan Berger