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: Stefan Berger <stefanb@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: Getting rid of xenbus_suspend(): tpmfront driver impacted?
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Sun, 05 Nov 2006 18:00:26 +0000
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sun, 05 Nov 2006 10:00:56 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <OFCB9FCD93.67AB2D0A-ON8525721D.005FA9AF-8525721D.0060D081@xxxxxxxxxx>
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
Thread-index: AccBBEVyhCn6Gmz3EdutFQANk04WTA==
Thread-topic: [Xen-devel] Re: Getting rid of xenbus_suspend(): tpmfront driver impacted?
User-agent: Microsoft-Entourage/11.2.5.060620
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