WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: Getting rid of xenbus_suspend(): tpmfront driver impacted?
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Sun, 5 Nov 2006 12:37:28 -0500
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sun, 05 Nov 2006 09:37:52 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C173C983.3DD2%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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