[Xen-devel] Re: [PATCH] [RFC] Fix a small window on CPU online/offline

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 01/04/2010 11:25, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:

> By the way, you could consider that c/s 21049 starts to take us down this
> path: the spin_trylock()/create_continuation() semantics is not totally
> dissimilar to Linux's mutex_lock (in which other softirqs/vcpus can get to
> run while we wait for the lock to be released), which are used for the
> cpu-hotplug related locks in Linux.

Thinking some more, we could even have more Linux-y mutex and completion
semantics if we allowed vcpus to be voluntarily preemptible in the Linux
way. Obviously our barrier to that currently is that we have per-cpu stacks,
not per-vcpu stacks.

One way to get around this without needing to hack out the concept of
per-cpu stacks would be to realise that all this mutex/completion stuff
would only get used on a few controloperation paths, mainly from
physdevop/sysctl/domctl -- i.e., dom0 management hypercalls. We could wrap
those up in a start_preemptible()/end_preemptible() region which would
alloc/free a shadow stack. Within those regions it would be safe to use new
mutex/completion abstractions which could then behave just like in Linux. We
would have an underlying mechanism which could copy the active stack out
into the shadow, adjust schedule_tail, and then do_softirq() to get into the
scheduler.

I don't know whether it is worth going this far, but perhaps it is easier to
have some easier-to-use synchronisation primitives like this in the long
run. You can certainly see it's going to mke the dom0 paths through Xen
easier to understand, and make code-borrowing from Linux a less difficult
and fragile proposition.

I could help with some of this, and/or what I described in my previous
email, by the way.

 -- Keir



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