* James Bottomley (j...@linux.ibm.com) wrote: > On Mon, 2023-01-09 at 16:59 +0000, Dr. David Alan Gilbert wrote: > > * Daniel P. Berrangé (berra...@redhat.com) wrote: > > > On Fri, Dec 16, 2022 at 08:32:44AM -0500, Stefan Berger wrote: > [...] > > > > I do see it because the *volatile state* cannot be extracted from > > > > this device. The state of the PCRs is going to be lost. > > > > > > All the objections you're raising are related to the current > > > specifics of the implementation of the mssim remote server. > > > While valid, this is of no concern to QEMU when deciding whether > > > to require a migration blocker on the client side. This is 3rd > > > party remote service that should be considered a black box from > > > QEMU's POV. It is possible to write a remote server that supports > > > the mssim network protocol, and has the ability to serialize > > > its state. Whether such an impl exists today or not is separate. > > > > We would normally want an example of a working implementation though > > wouldn't we? > > > > So I think it's fair to at least want some documentation; if it can > > be documented and works, fine; if it doesn't work, then it needs a > > blocker. > > It works under limited circumstances ... in fact similar circumstances > passthrough migration works under,
Well, not that similar - people expect passthrough migration to fail because, being nailed to a physical servers hardware it's not likely to migrate; where as you're creating a new virtual thing which people might imagine is similar to the existing swtpm. Their imagination might be wrong and thus you need to say why. > which is also not documented. The Inductive proof that we should have no good documentation doesn't get us anywhere. > external MSSIM TPM emulator has to be kept running to preserve the > state. If you restart it, the migration will fail. Document that and we're getting there. Dave > James > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
