On 05/28/2011 10:45 PM, Sasha Levin wrote:
On Sat, 2011-05-28 at 17:24 +0200, Ingo Molnar wrote: > * Sasha Levin<levinsasha928@xxxxxxxxx> wrote: > > > So the basic plan here is to allocate a futex(?) for each VCPU > > thread, and have the writer thread lock all futexes when it needs > > to write? > > > > If we assume we only have one writer thread, it can stay pretty > > simple. > > We can use an even simpler and more scalable method: > > - writers can 'stop' all other threads, by sending them a > threadpool signal and waiting for each thread to have completed > processing their current work and notifying the writer back that > they have stopped running. > > This means that the read-side lock is _zero instructions_, basically > just a barrier() to make sure the compiler does not move instructions > across threadpool functions (it wont). > > This method requires that we know about every worker thread - i.e. > no-one does a stray pthread_create() and uses data structures from > there. It also requires that each worker thread can 'stop' within a > reasonable amount of time. In this case, maybe instead of implementing it as a 'lock', we can implement it as a way to stop all vcpu threads from reentering the kernel (KVM_RUN): 1. Set a 'vcpu-stop' flag. 2. Signal all VCPUs to exit KVM_RUN. 3. VCPU threads now wait on our lock before reentering into KVM_RUN - the writer thread waits until waiting threads = VCPU count. 4. Writer thread writes, releases lock. So instead of it being a lock in MMIO, IO-ports, etc - it's a method to stop the entire guest which could be used during configuration updates (and anything else we might think of). It could also be used as a method for users to 'pause' the guest.
Yes, this is equivalent to the kernel's stop_machine_run(). It's a heavyweight method but it should work just fine.
-- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
