Xen devel - Jul 2005 - domain_pause and vcpu_pause on currently executing domain?

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?

  -George

+-------------------+----------------------------------------
| dunlapg@umich.edu | 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
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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.

Peace,
  -George


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@umich.edu | 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
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 18 Jul 2005, at 21:55, George Washington Dunlap III wrote:
> 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.
{domain,vcpu}_pause are based on a counter, not a bit. These are what 
you can call from within Xen, so if that is where you are implementing 
stuff you shouldn''t need your own functions.

domain_pause_by_systemcontroller(), which is what is accessible from 
outside Xen itself, is based on a single bit.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel