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] domain_pause and vcpu_pause on currently executing domai

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] domain_pause and vcpu_pause on currently executing domain?
From: George Washington Dunlap III <dunlapg@xxxxxxxxx>
Date: Mon, 18 Jul 2005 16:55:58 -0400 (EDT)
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 18 Jul 2005 20:54:40 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <2a6dc0f132f12a5920639040ba5a06b2@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>
References: <Pine.LNX.4.60.0507181627230.21790@xxxxxxxxxxxxxxxxxxxxxx> <2a6dc0f132f12a5920639040ba5a06b2@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Yeah, I think I see the confusion now: one might think that vcpu_pause(current) would be the same as a yield() [if such a function actually existed].

I'm testing out alternate versions of the functions, vcpu_pause_delay() and domain_pause_delay(), which will explicitly is supposed to raise a softirq and return if vcpu == current.

We're using basically the exact same functionality, with a pause/unpause "counter" rather than a bit, with our execution replay system. In our current implementation, there are a number of different threads of the replay system, each doing a small set of things: one is delivering interrupts, doing scheduling, etc.; but we have separate threads called "replay drivers" which sit between the replaying domain and the thing they're talking to. All of these competeing interests want to pause and unpause the domain, and having just a bit isn't enough.

But I'd naturally rather use mainline xen functionality, than maintain my own copy, if I can.


On Mon, 18 Jul 2005, Keir Fraser wrote:

On 18 Jul 2005, at 21:33, George Washington Dunlap III wrote:

I just discovered the domain_pause() and vcpu_pause() functionality, and i was wondering why the functions call BUG if the target domain/vcpu is currently executing. It seems like being able to say, "Pause the currently running domain as soon as this hypervisor event is done" would be a useful one; all that would be required is having domain_sleep_sync() raise the schedule softirq if it's the currently executing one.

Was there a particular reason this was implemented this way? Or was the use I described not envisioned?

We do have something a bit like that, for debuggers (domain_pause_for_debugger). Apart from that, I'm not sure what it would be useful for. Well, actually it would be useful if you could pause the current domain to get it off the scheduler runqueues but still carry on your current thread of execution within Xen. But Xen context switching (on x86 at least) doesn't really allow that. And if you can't do that, hacks to make domain_pause() at least appear to work for the currently-executing domain probably aren;t very useful and would quite likely lead to confused people writing subtly broken code. :-)

Those interfaces are still open for comments though, and can change if there is a strong argument to do so.

-- Keir

| dunlapg@xxxxxxxxx | http://www-personal.umich.edu/~dunlapg +-------------------+----------------------------------------
|  Who could move a mountain, who could love their enemy?
|  Who could rejoice in pain, and turn the other cheek?
|       - Rich Mullins, "Surely God is With Us"
| Outlaw Junk Email! Support HR 1748 (www.cauce.org)

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>