From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nx3sT-0007l3-2X for qemu-devel@nongnu.org; Wed, 31 Mar 2010 15:47:01 -0400 Received: from [140.186.70.92] (port=35343 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nx3sR-0007kf-Qk for qemu-devel@nongnu.org; Wed, 31 Mar 2010 15:47:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nx3sP-0002ts-Od for qemu-devel@nongnu.org; Wed, 31 Mar 2010 15:46:59 -0400 Received: from mail-pw0-f45.google.com ([209.85.160.45]:46237) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nx3sP-0002tm-IX for qemu-devel@nongnu.org; Wed, 31 Mar 2010 15:46:57 -0400 Received: by pwi6 with SMTP id 6so464348pwi.4 for ; Wed, 31 Mar 2010 12:46:56 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4BB3A183.8000905@codemonkey.ws> References: <20100331182031.GA5200@redhat.com> <4BB393CF.1040700@codemonkey.ws> <20100331153805.03ee142e@redhat.com> <20100331190753.GA6914@redhat.com> <4BB3A183.8000905@codemonkey.ws> Date: Wed, 31 Mar 2010 22:46:56 +0300 Message-ID: Subject: Re: [Qemu-devel] Re: [PATCH] vhost: fix features ack From: Blue Swirl Content-Type: text/plain; charset=UTF-8 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Luiz Capitulino , qemu-devel@nongnu.org, "Michael S. Tsirkin" On 3/31/10, Anthony Liguori wrote: > On 03/31/2010 02:07 PM, Michael S. Tsirkin wrote: > > > On Wed, Mar 31, 2010 at 03:38:05PM -0300, Luiz Capitulino wrote: > > > > > > > On Wed, 31 Mar 2010 13:26:23 -0500 > > > Anthony Liguori wrote: > > > > > > > > > > > > > On 03/31/2010 01:20 PM, Michael S. Tsirkin wrote: > > > > > > > > > > > > > From: David L Stevens > > > > > > > > > > vhost driver in qemu didn't ack features, and this happens > > > > > to work because we don't really require any features. However, > > > > > it's better not to rely on this. This patch passes features to > > > > > vhost as guest acks them. > > > > > > > > > > Signed-off-by: David L Stevens > > > > > Signed-off-by: Michael S. Tsirkin > > > > > --- > > > > > > > > > > Anthony, here's a fixup patch to address an issue in vhost > > > > > patches. Incidentially, what's the status of the vhost patchset? > > > > > > > > > > > > > > > > > > > > http://repo.or.cz/w/qemu/aliguori-queue.git > vhost > > > > > > > > Is what I'm currently testing. With vhost disabled, the following > seg > > > > faults: > > > > > > > > qemu-system-x86_64 -hda ~/images/linux.img -net tap -net > > > > nic,model=virtio -enable-kvm > > > > > > > > But not when using TCG. I'm not sure that it's your patches at fault > > > > and I'm attempting to bisect now to figure that out. > > > > > > > > > > > Probably this is the same segfault I'm getting right > now in master, > > > bisect says it's: > > > > > > """ > > > commit ad96090a01d848df67d70c5259ed8aa321fa8716 > > > Author: Blue Swirl > > > Date: Mon Mar 29 19:23:52 2010 +0000 > > > > > > Refactor target specific handling, compile vl.c only once > > > """ > > > > > > > > Why are the compile once patches helpful? They seem to > introduce > > churn and bugs, they actively make it harder to extend qemu as you can't > use > > target-specific code in code that is compiled once, they might have > > performance penalty - and what do we gain? Any given user is unlikely to > > need to build on more than one target, distros have enough computing > > power to build in parallel. > > > > Maybe it makes sense to revert the compile once patches, and discuss > > these issues before re-commit? > > > > > > Compiling objects once is certainly useful. Long term, I think most of us > want to see a single qemu executable that works for all architectures and > compiling once is an important step in that direction. > > With respect to regressions, it might make sense to slow down these > refactorings a bit and increase the amount of regression testing that is > happening during them. I think there are only a few useful refactorings left. MIPS was interesting because of fourfold savings, likewise triple savings with PPC. Refactoring i386/x86_64 devices may be worthwhile, the rest not.