[Qemu-devel] Re: kvm crashes with spice while loading qxl

[Marcelo Tosatti]

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.

>  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.

Is write access to memory map necessary from vcpu context?

> During execution, tcg accesses memory a lot.  So we'll need to
> acquire qemu_global_mutex for every memory access, and separate
> protection for TB.
> 
> kvm achieves lockless protection by forcing vcpus off and dropping
> their page tables while executing natively, and using srcu while
> emulating.  We can do something similar for tcg, but it won't be
> easy.
> 
> >Of course for memory or PIO accesses from vcpu context qemu_global_mutex
> >must be acquired.
> 
> Yes, and not just mmio - all memory accesses.
> 
> >With that in place, it becomes easier to justify further improvements
> >regarding parallelization, such as using a read-write lock for
> >l1_phys_map / phys_page_find_alloc.
> >
> >
> >  21.62%               sh            3d38920b3f  [.] 0x00003d38920b3f
> >   6.38%               sh  qemu-system-x86_64    [.] phys_page_find_alloc
> 
> should be replaced by a memslot list probably
> 
> >   4.90%               sh  qemu-system-x86_64    [.] tb_find_fast
> >   4.34%               sh  qemu-system-x86_64    [.] tlb_flush
> >
> 
> 
> -- 
> error compiling committee.c: too many arguments to function