From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] Re: KVM call minutes for Feb 1 Date: Thu, 03 Feb 2011 07:48:18 -0600 Message-ID: <4D4AB222.6030204@codemonkey.ws> References: <20110201155414.GF28968@x200.localdomain> <4D48367D.2060802@siemens.com> <4D483A9B.9000205@codemonkey.ws> <4D483CCF.60009@siemens.com> <4D4840CE.5020700@codemonkey.ws> <4D48443A.80108@siemens.com> <20110203101116.GA2734@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , Chris Wright , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" To: Marcelo Tosatti Return-path: Received: from mail-vx0-f174.google.com ([209.85.220.174]:59669 "EHLO mail-vx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756407Ab1BCNzn (ORCPT ); Thu, 3 Feb 2011 08:55:43 -0500 Received: by vxb37 with SMTP id 37so294278vxb.19 for ; Thu, 03 Feb 2011 05:55:42 -0800 (PST) In-Reply-To: <20110203101116.GA2734@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On 02/03/2011 04:11 AM, Marcelo Tosatti wrote: > On Tue, Feb 01, 2011 at 06:34:50PM +0100, Jan Kiszka wrote: > >> On 2011-02-01 18:20, Anthony Liguori wrote: >> >>> On 02/01/2011 11:03 AM, Jan Kiszka wrote: >>> >>>> On 2011-02-01 17:53, Anthony Liguori wrote: >>>> >>>> >>>>> On 02/01/2011 10:36 AM, Jan Kiszka wrote: >>>>> >>>>> >>>>>> On 2011-02-01 16:54, Chris Wright wrote: >>>>>> >>>>>> >>>>>> >>>>>>> KVM upstream merge: status, plans, coordination >>>>>>> - Jan has a git tree, consolidating >>>>>>> - qemu-kvm io threading is still an issue >>>>>>> - Anthony wants to just merge >>>>>>> - concerns with non-x86 arch and merge >>>>>>> - concerns with big-bang patch merge and following stability >>>>>>> - post 0.14 conversion to glib mainloop, non-upstreamed qemu-kvm will be >>>>>>> a problem if it's not there by then >>>>>>> - testing and nuances are still an issue (e.g. stefan berger's mmio read issue) >>>>>>> - qemu-kvm still evolving, needs to get sync'd or it will keep diverging >>>>>>> - 2 implementations of main init, cpu init, Jan has merged them into one >>>>>>> - qemu-kvm-x86.c file that's only a few hundred lines >>>>>>> - review as one patch to see the fundamental difference >>>>>>> >>>>>>> >>>>>>> >>>>>> More precisely, my current work flow is to pick some function(s), e.g. >>>>>> kvm_cpu_exec/kvm_run, and start wondering "What needs to be done to >>>>>> upstream so that qemu-kvm could use that implementation?". If they >>>>>> differ, the reasons need to be understood and patched away, either by >>>>>> fixing/enhancing upstream or simplifying qemu-kvm. Once the upstream >>>>>> changes are merged back, a qemu-kvm patch is posted to switch to that >>>>>> version. >>>>>> >>>>>> Any help will be welcome, either via review of my subtle regressions or >>>>>> on resolving concrete differences. >>>>>> >>>>>> E.g. posix-aio-compat.c: Why does qemu-kvm differ here? If it's because >>>>>> of its own iothread code, can we wrap that away or do we need to >>>>>> consolidate the threading code first? Or do we need to fix something in >>>>>> upstream? >>>>>> >>>>>> >>>>>> >>>>> I bet it's the eventfd thing. It's arbitrary. If you've got a small >>>>> diff post your series, I'd be happy to take a look at it and see what I >>>>> can explain. >>>>> >>>>> >>>>> >>>> Looks like it's around signalfd and its emulation: >>>> >>>> >>> I really meant the compatfd thing. >>> >>> signalfd can't really be emulated properly so in upstream we switched to >>> a pipe() which Avi didn't like. >>> >>> But with glib, this all goes away anyway so we should just drop the >>> qemu-kvm changes and use the upstream version. Once we enable I/O >>> thread in qemu.git, we no longer need to use signals for I/O completion >>> which I think everyone would agree is a better solution. >>> >> Don't understand: If we do not need SIGIO for AIO emulation in threaded >> mode, why wasn't that stubbed out already? If that helps reducing >> worries about the signalfd emulation (which is likely a non-issue anyway >> as anyone with serious workload should run a kernel with such support). >> > qemu-kvm has this modification for performance reasons. > SIGUSR2 can't be blocked otherwise. See example test case at > https://patchwork.kernel.org/patch/20817/. > That test-case is not realistic. That's 10k signals per second. With batching, we're at an I/O op rate that we're not even close to today. I can guarantee that you won't find a real workload were you can actually measure the difference. And keep in mind, the signal notification should go away so having this change in qemu-kvm really doesn't make sense. Regards, Anthony Liguori