[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: Getting rid of xenbus_suspend(): tpmfront driver impacted?
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 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 bit cheesy as far as I can see, so something more integrated in the tpmfront/back protocol would be nice. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |