From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NxAQk-0000yD-4K for qemu-devel@nongnu.org; Wed, 31 Mar 2010 22:46:50 -0400 Received: from [140.186.70.92] (port=48760 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NxAQi-0000y5-WA for qemu-devel@nongnu.org; Wed, 31 Mar 2010 22:46:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NxAQh-0007tg-Iw for qemu-devel@nongnu.org; Wed, 31 Mar 2010 22:46:48 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:59599) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NxAQh-0007tc-EP for qemu-devel@nongnu.org; Wed, 31 Mar 2010 22:46:47 -0400 Received: by gwaa20 with SMTP id a20so553063gwa.4 for ; Wed, 31 Mar 2010 19:46:46 -0700 (PDT) Message-ID: <4BB40914.9060804@codemonkey.ws> Date: Wed, 31 Mar 2010 21:46:44 -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: <4BB408CF.9040004@codemonkey.ws> 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: Aurelien Jarno Cc: blauwirbel@gmail.com, Luiz Capitulino , qemu-devel@nongnu.org, "Michael S. Tsirkin" On 03/31/2010 09:45 PM, 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. > > I'm thinking we should back out the vl.c changes and try to clean up > the KVM bits first. Does that sound reasonable blueswirl or can you > think of a cleaner way to deal with kvm? And back out can just mean making vl.c compile per-target (along with the thinko fix in acpi.c). That would be a nice temporary solution until we worked out the kvm_enabled() bits correctly. Regards, Anthony Liguori > Regards, > > Anthony Liguori >