Re: [Xen-devel] Re: Getting rid of xenbus_suspend(): tpmfront driver impacted?

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 5/11/06 5:37 pm, "Stefan Berger" <stefanb@xxxxxxxxxx> wrote:

> 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. 
If we could do this then we could simply send the ring-buffer page after the VTPM has quiesced. Then the response would be sitting there for tpmfront to pick up on resume, which would be much nicer than the tpmfront_suspend() ‘wait for a bit’ loop. But I expect it’s a bit of a pain to integrate into the current save/restore code.
> > 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? 

Well, we are going to handle save/restore and migration failure by continuing execution of the original domain. In this case xenbus_resume() will not be executed, so tpmfront will (I think) hang.

I suppose we could keep suspend() and also introduce a suspend_cancelled() hook...

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel