[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: Getting rid of xenbus_suspend(): tpmfront driver impacted?


  • To: Stefan Berger <stefanb@xxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Sun, 05 Nov 2006 17:01:55 +0000
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Sun, 05 Nov 2006 09:02:18 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AccA/Bi6VyisrmzvEdutFQANk04WTA==
  • Thread-topic: Getting rid of xenbus_suspend(): tpmfront driver impacted?

The TPM protocol in contrast assumes a reliable connection from the computer to the device and that all commands finish correctly and responses are received by the apps *and* that requests are not resent. How does the block driver handle this? Will the frontend driver still receive explicit notification of a shutdown?

What’s the story on save/restore/migration of TPM state so that the guest sees the expected state on restore? It’s not like it’s part of the save image format right now. Assuming you have some out-of-band mechanism, how about making a message counter (or something) a part of that save state and something that tpmfront can interrogate when it reconnects to find out exactly up to what point in its request stream processing ceased? The current tpmfront_suspend() method is a bit cheesy as far as I can see, so something more integrated in the tpmfront/back protocol would be nice.

 -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.