From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] [RFC] Fix a small window on CPU online/offline Date: Thu, 01 Apr 2010 11:33:53 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Jiang, Yunhong" Cc: "xen-devel@lists.xensource.com" , Jan Beulich List-Id: xen-devel@lists.xenproject.org On 01/04/2010 11:25, "Keir Fraser" 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