From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] Re: KVM call agenda for Feb 9 Date: Tue, 09 Feb 2010 16:38:25 +0200 Message-ID: <4B717361.3000307@redhat.com> References: <20100209012851.GJ25751@x200.localdomain> <4B710714.1020109@redhat.com> <02FDE8B6-CCC9-4EA5-B7EB-6EFC6497C268@suse.de> <4B712249.4020703@web.de> <4B716EC7.1010900@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , Alexander Graf , Chris Wright , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:24238 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754504Ab0BIOic (ORCPT ); Tue, 9 Feb 2010 09:38:32 -0500 In-Reply-To: <4B716EC7.1010900@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On 02/09/2010 04:18 PM, Anthony Liguori wrote: > On 02/09/2010 02:52 AM, Jan Kiszka wrote: >> Alexander Graf wrote: >>> On 09.02.2010, at 07:56, Avi Kivity wrote: >>>> - rcuify/fine-grain qemu locks >>> And this should be done either way, but is probably not a short-term >>> goal. >>> >> Indeed. We won't get around this longterm as it is a scalability >> bottleneck and a killer for RT guest load. We can't push everything into >> the kernel. Qemu needs a smart plan how to gradually convert its CPU and >> device model to fine-grained locking. > > The VCPU loops should be easy to convert to lockless operation. It's > easier to do this upstream but that requires a functioning IO thread. > > For the table based MMIO and PIO dispatch, RCU would be a good locking > choice since these structures are rarely updated. The tricky bit is > that the APIC has to be converted over to lockless before any other > device can be converted because just about every device wants to > inject an interrupt. The problem is that all the internal APIs now have to be threaded. Looking at hpet as a simple example, we have qemu_irq_pulse() and qemu_mod_timer(). We also have some lock inversion since hpet calls the timer but the timers also call hpet. qemu_irq_pulse() feeds the various interrupt controllers; not a problem for kernel irqchip but nontrivial for qemu's ioapic and pic. I'm not saying we should push hpet into the kernel to save userspace coding effort; there should be an independent reason to do this. But I don't think threading qemu is going to be anything near easy. -- error compiling committee.c: too many arguments to function