Re: [PATCH 2/2] tpm: add backend for mssim

[Stefan Berger <stefanb@linux.ibm.com>]

On 12/19/22 08:02, James Bottomley wrote:
> On Mon, 2022-12-19 at 06:49 -0500, Stefan Berger wrote:
>>
>>
>> On 12/16/22 08:53, James Bottomley wrote:
>>
>>>
>>> I could do a blog post, but I really don't think you want this in
>>> official documentation because that creates support expectations.
>>
>> We get support expectations if we don't mention it as not being
>> supported. So, since this driver is not supported the documentation
>> for QEMU should state something along the lines of 'this driver is
>> for experimental or testing purposes and is otherwise unsupported.'
>> That's fair to the user and maintainer.
> 
> Open source project don't provide support.  I already added a
> Maintainer entry for it, so I'll maintain it.

Support for me means reacting to user questions and addressing issues. Good that you maintain this now.

> 
>>   Nevertheless, if the documentation (or as a matter of fact the code)
>> was to claim that VM / TPM state migration scenarios, such as VM
>> snapshotting, are working then users should be able to ask someone
>> 'how' this can be done with the mssim protocol **today**. Since I
>> cannot answer that question you may need to find a way for how to
>> address this concern.
> 
> I already proposed all of this ... you were the one wanting to document
> migration.  The current wording is:

With documenting I wanted to see how users need to provide command lines for the mssim TPM.

> 
>     The mssim backend supports snapshotting and migration, but the state
>     of the Microsoft Simulator server must be preserved (or the server
>     kept running) outside of QEMU for restore to be successful.

VM snapshotting is basically VM suspend / resume on steroids requiring permanent and volatile state to be saved and restoreable from possible very different points in time with possibly different seeds, NVRAM locations etc. How the mssim protocol does this is non-obvious to me and how one coordinates the restoring and saving of the TPM's state without direct coordination by QEMU is also non-obvious.

    Stefan

> 
> James
> 
>