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

[Stefan Berger <stefanb@xxxxxxxxxx>]

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