From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NxMwl-0005AO-SI for qemu-devel@nongnu.org; Thu, 01 Apr 2010 12:08:43 -0400 Received: from [140.186.70.92] (port=48017 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NxMwj-00058D-NS for qemu-devel@nongnu.org; Thu, 01 Apr 2010 12:08:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NxMwh-00005Z-Rk for qemu-devel@nongnu.org; Thu, 01 Apr 2010 12:08:41 -0400 Received: from mail-iw0-f199.google.com ([209.85.223.199]:60481) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NxMwh-00005O-OB for qemu-devel@nongnu.org; Thu, 01 Apr 2010 12:08:39 -0400 Received: by iwn37 with SMTP id 37so935629iwn.15 for ; Thu, 01 Apr 2010 09:08:38 -0700 (PDT) Message-ID: <4BB4C503.1060400@codemonkey.ws> Date: Thu, 01 Apr 2010 11:08:35 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] vhost: fix features ack References: <20100331182031.GA5200@redhat.com> <4BB393CF.1040700@codemonkey.ws> <20100331153805.03ee142e@redhat.com> <20100331190753.GA6914@redhat.com> <4BB3A183.8000905@codemonkey.ws> <20100331224541.GB19306@hall.aurel32.net> <4BB408CF.9040004@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Luiz Capitulino , qemu-devel@nongnu.org, Aurelien Jarno , "Michael S. Tsirkin" On 04/01/2010 10:54 AM, Blue Swirl wrote: > On 4/1/10, Anthony Liguori wrote: > >> On 03/31/2010 05:45 PM, Aurelien Jarno wrote: >> >> >>> While it probably make sense to achieve this goal, it doesn't mean it >>> should be done the dirty way. >>> >>> For example it is known for a lot of time that the solution for the >>> bswap in the device code is to add a bus model doing the byteswapping. >>> Removing the #ifdef by deciding "this device will only be big/little >>> endian" doesn't seem to go in the right direction. >>> >>> >>> >> Yeah, I'm having real trouble with the KVM regression. I thought I had it >> fixed but linux-user really made a mess of things. There's no simple >> solution that doesn't require quite a bit of refactoring which I'd rather do >> in a less ugly way. We've already been discussing getting rid of all the >> kvm_enabled() stuff and I think doing that properly is going to be needed to >> handle this correctly. >> > Strange, does linux-user use kvm.h (indirectly)? > Yes, because various things in target-i386 use kvm.h. Regards, Anthony Liguori