On Fri, Oct 11, 2024 at 10:46:58AM -0400, Stefan Berger wrote: > > > On 10/11/24 10:32 AM, Marc-André Lureau wrote: > > Hi > > > > On Fri, Oct 11, 2024 at 6:17 PM Stefan Berger <stefanb@xxxxxxxxxxxxx> wrote: > > > > > > > > > > > > On 10/11/24 10:10 AM, Marc-André Lureau wrote: > > > > Hi > > > > > > > > On Fri, Oct 11, 2024 at 5:49 PM Stefan Berger <stefanb@xxxxxxxxxxxxx> wrote: > > > > > > > > > > > > > > > > > > > > On 10/4/24 9:32 AM, marcandre.lureau@xxxxxxxxxx wrote: > > > > > > From: Marc-André Lureau <marcandre.lureau@xxxxxxxxxx> > > > > > > > > > > > > Learn to parse a file path for the TPM state. > > > > > > > > > > > > Signed-off-by: Marc-André Lureau <marcandre.lureau@xxxxxxxxxx> > > > > > > --- > > > > > > docs/formatdomain.rst | 19 ++++++++++++++ > > > > > > src/conf/domain_conf.c | 28 +++++++++++++++++++++ > > > > > > src/conf/domain_conf.h | 9 +++++++ > > > > > > src/conf/schemas/domaincommon.rng | 14 +++++++++++ > > > > > > tests/qemuxmlconfdata/tpm-emulator-tpm2.xml | 1 + > > > > > > 5 files changed, 71 insertions(+) > > > > > > > > > > > > diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst > > > > > > index 4336cff3ac..992bb98730 100644 > > > > > > --- a/docs/formatdomain.rst > > > > > > +++ b/docs/formatdomain.rst > > > > > > @@ -8173,6 +8173,25 @@ Example: usage of the TPM Emulator > > > > > > The default version used depends on the combination of hypervisor, guest > > > > > > architecture, TPM model and backend. > > > > > > > > > > > > +``source`` > > > > > > + The ``source`` element specifies the location of the TPM state storage . This > > > > > > + element only works with the ``emulator`` backend. > > > > > > + > > > > > > + If not specified, the storage configuration is left to libvirt discretion. > > > > > > + > > > > > > + This element requires that swtpm v0.7 or later is installed. > > > > > > + > > > > > > + The following attributes are supported: > > > > > > + > > > > > > + ``type`` > > > > > > + The type of storage. It's possible to provide "file" to utilize a single > > > > > > + file or block device where the TPM state will be stored. > > > > > > + > > > > > > + ``path`` > > > > > > + The path to the TPM state storage. > > > > > > > > > > The file backend of swtpm does not do the locking similar to what the > > > > > dir backend does because those who added the file backend didn't > > > > > need/want it. If we now give full control to the path of the TPM state > > > > > file to the user via the domain XML then whose fault is it if two VMs > > > > > use the same path to a file backend and stomp on the TPM state file? Is > > > > > it the fault of the user because of how he defined the path in the XMLs? > > > > > > > > Imho, it's desirable to have a similar locking behaviour regardless of > > > > the backend and prevent users for mistakenly using the same file. > > > > > > We will only be able to support the locking with an option on the > > > command line for swtpm (refelected by a new capability verb) and support > > > this series here once that has become available with a new version of > > > swtpm. Otherwise I would avoid giving full control to the path to the > > > users but let libvirt choose a per-VM unique name for the state file. > > > > The use-case is to let the user define a specific block device path. > > Why would they store it on a block device rather than a file system? If they want to make the storage available to multiple hosts, then using a block device is simpler, as most filesystems are unsafe to concurrently expose in multiple hosts. With 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 :|
