[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: Getting rid of xenbus_suspend(): tpmfront driver impacted?
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |