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/
Home Products Support Community News


Re: [Xen-devel] resume of HVM guest without PV drivers

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] resume of HVM guest without PV drivers
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Fri, 07 Aug 2009 11:13:58 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 07 Aug 2009 03:14:22 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4A7C15B1020000780000E9D3@xxxxxxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcoXROYq0DALpCc4T72S+CD09apvPwAAuCxi
Thread-topic: [Xen-devel] resume of HVM guest without PV drivers
User-agent: Microsoft-Entourage/
On 07/08/2009 10:53, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:

>> If you only care about being able to poll for having migrated/saved, there
>> must be some other bit of state you can push to Xen that doesn't get
>> migrated/saved. Like, create an IPI event channel and poll its status
>> (EVTCHNOP_status).
> No, a hypercall of any sort is not a good option (namely if I wanted to
> use a hypercall page, which I'm not certain about yet, as that would
> create a chicken-and-egg problem). It must be some memory state that
> I can examine.

So what does improving ticket lock behaviour have to do with save/restore?
I'm a bit confused now.

> And with the goal of improving lock behavior, I also definitely will need to
> have a way to know whether a remote vCPU is currently running, and
> here it is obviously preferable to not have to use a hypercall to find out
> (i.e. I'd want the runstate area change I'm looking at anyway).

I'll certainly consider the patch. I'd also consider a CPUID flag to
indicate its presence.

 -- Keir

Xen-devel mailing list