|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Re: Getting rid of xenbus_suspend(): tpmfront driver imp
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
|
|
|
|
|