WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: Getting rid of xenbus_suspend(): tpmfront driver impacted?
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Mon, 6 Nov 2006 10:35:08 -0500
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 06 Nov 2006 07:36:24 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C173D73A.3DDE%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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