Re: [PATCH 4/6] kvm tools: Add rwlock wrapper

[Sasha Levin <levinsasha928@gmail.com>]

On Sat, 2011-05-28 at 17:24 +0200, Ingo Molnar wrote:
> * Sasha Levin <levinsasha928@gmail.com> 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.

-- 

Sasha.