From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] Re: KVM call agenda for Feb 9 Date: Tue, 09 Feb 2010 09:08:37 -0600 Message-ID: <4B717A75.3010300@codemonkey.ws> 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> 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: Avi Kivity Return-path: Received: from mail-iw0-f183.google.com ([209.85.223.183]:44584 "EHLO mail-iw0-f183.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753998Ab0BIPIl (ORCPT ); Tue, 9 Feb 2010 10:08:41 -0500 Received: by iwn13 with SMTP id 13so8087391iwn.25 for ; Tue, 09 Feb 2010 07:08:40 -0800 (PST) In-Reply-To: <4B717361.3000307@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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