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