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

[Stefan Berger <stefanb@xxxxxxxxxx>]

xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 11/05/2006
01:00:26 PM:

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

Yes, it would hang. Some notification would be necessary
to have it resume.

   Stefan

> 
> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel