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