[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: [PATCH] [RFC] Fix a small window on CPU online/offline
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |