From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nerhk-00047W-2o for qemu-devel@nongnu.org; Tue, 09 Feb 2010 10:08:44 -0500 Received: from [199.232.76.173] (port=47970 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nerhj-00046B-DZ for qemu-devel@nongnu.org; Tue, 09 Feb 2010 10:08:43 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nerhh-0004Cx-Qt for qemu-devel@nongnu.org; Tue, 09 Feb 2010 10:08:43 -0500 Received: from mail-iw0-f176.google.com ([209.85.223.176]:47866) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nerhh-0004Ct-HT for qemu-devel@nongnu.org; Tue, 09 Feb 2010 10:08:41 -0500 Received: by iwn6 with SMTP id 6so3984546iwn.15 for ; Tue, 09 Feb 2010 07:08:40 -0800 (PST) Message-ID: <4B717A75.3010300@codemonkey.ws> Date: Tue, 09 Feb 2010 09:08:37 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: KVM call agenda for Feb 9 References: <20100209012851.GJ25751@x200.localdomain> <4B710714.1020109@redhat.com> <02FDE8B6-CCC9-4EA5-B7EB-6EFC6497C268@suse.de> <4B712249.4020703@web.de> <4B716EC7.1010900@codemonkey.ws> <4B717361.3000307@redhat.com> In-Reply-To: <4B717361.3000307@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Chris Wright , Jan Kiszka , Alexander Graf , kvm@vger.kernel.org, qemu-devel@nongnu.org On 02/09/2010 08:38 AM, Avi Kivity wrote: > 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(). Yes. But just as you mention, we have to approach it on a device-by-device basis and incrementally convert over devices. > We also have some lock inversion since hpet calls the timer but the > timers also call hpet. Right. Making the dispatch loop in the IO thread thread safe won't be so bad either :-) > 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. It's certainly not easy but I don't think it's impossibly hard. Regards, Anthony Liguori