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, or move the memory map.
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
