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

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

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: [Xen-devel] Re: Getting rid of xenbus_suspend(): tpmfront driver impacted?
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Sun, 5 Nov 2006 11:27:37 -0500
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 05 Nov 2006 08:28:02 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C17386C8.3DBC%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

Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> wrote on 11/05/2006 07:17:12 AM:

>
> I'm planning to get xenbus_suspend() as part of work to move device
> reconnection work all to the restore side of save/restore. This will make
> restarting a suspended guest much easier if save/restore/relocation fails
> for any reason.
>
> Currently the only consumer of xenbus_suspend() is the tpmfront driver. So
> this is mainly a heads up that, whatever it is doing with that hook, it'll
> need to find some way round it. Perhaps it can use techniques employed in
> other frontend drivers to do all the necessary work on resume?


Thanks for the heads up.
The problem with the TPM is that I need a mechanisms to wait for a request that has been sent to the TPM to finish and get the response back since any command can change the internal state of that device, like for example one of its registers. So resending a command after the resume would not be correct since this can change the internal state again, which would lead to an incorrect state. I am not as fimiliar with how the other drivers are handling the shutdown, but I know that any program using a networking protocol will need to recover from losses of UDP packets by itself and TCP does this automatically anyway -- thererfore there it is not necessary to wait for outstanding reponses. 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?
 
  Stefan

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