|   | 
      | 
  
  
      | 
      | 
  
 
     | 
    | 
  
  
     | 
    | 
  
  
    |   | 
      | 
  
  
    | 
         
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
 
 |   
 
 | 
    | 
  
  
    |   | 
    |