On 03/07/2011 06:13 PM, Marcelo Tosatti wrote:
On Sun, Mar 06, 2011 at 12:38:44PM +0200, Avi Kivity wrote:
> On 03/05/2011 06:35 PM, Marcelo Tosatti wrote:
> >Regarding global mutex, TCG and KVM execution behaviour can become more
> >similar wrt locking by dropping qemu_global_mutex during generation and
> >execution of TBs.
>
> How can you do that? During generation, a device can assert the
> reset line, changing cpu modes,
Writes to CPUState fields needs can moved to vcpu thread context
(run_on_cpu), and reads performed under a lock.
Good thing is most CPUState accesses are local to vcpu context.
That's a really good idea. And in fact that's what we do in kvm, if we
have something to do to a cpu we queue it up in vcpu->requests and let
the vcpu thread process it.
> or move the memory map.
Memory map can be protected by a read-write lock initially, so that vcpu
thread holds it for read. Later can be converted to URCU.
rwlock is insufficient, need a way to force the vcpu off so a writer can
actually do something.
So we need some kind of priority rwlock where a reader lets the lock
know how it can force it off in case a writer comes along.
Is write access to memory map necessary from vcpu context?
Yes, examples writes to PCI BARs or the VGA windows at 0xa0000.
We can move them to a device thread, but the vcpu thread will have to
wait for it (so it needs to drop any locks anyway).
--
error compiling committee.c: too many arguments to function
