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

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




xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 11/05/2006 12:01:55 PM:

> 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


For that there is the external device migration facility in Xend that is used to tell a virtual TPM to serialize its state and can have its state transferred over the network. However, a virtual TPM cannot serialize its state as long as its processing a command, such as for example if it's busy creating a key pair. So for that reason its necessary to wait for an issued command to finish anyway. Using the suspend method I could so far catch the response for that command.

> 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


As I said above, the last command (and there's only one command being processed at a time for an OS) must have finished anyway. So a mechanisms would have to be to tell the virtual TPM to catch that last response instead of sending it into /dev/vtpm on the backend side, and have that last response serialized as part of the state *before* the VM is shut down. This might be much more complicated, though.

> bit cheesy as far as I can see, so something more integrated in the
> tpmfront/back protocol would be nice.


In terms of time needed for migration there won't be a difference. Is supporting that .suspend really so problematic?

   Stefan

>
>  -- Keir_______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
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®.