From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Subject: Re: [Qemu-devel] Re: [PATCH v2] qemu-kvm: Speed up of the dirty-bitmap-traveling Date: Wed, 10 Feb 2010 17:43:16 +0100 Message-ID: <4B72E224.1090901@suse.de> References: <4B728FF9.6010707@lab.ntt.co.jp> <4B72B28E.6010801@redhat.com> <4B72D69D.7050005@codemonkey.ws> <4B72D838.9060603@suse.de> <4B72E051.8090008@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: Avi Kivity , OHMURA Kei , mtosatti@redhat.com, "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , Anthony Liguori To: Anthony Liguori Return-path: Received: from cantor.suse.de ([195.135.220.2]:37781 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754796Ab0BJQnS (ORCPT ); Wed, 10 Feb 2010 11:43:18 -0500 In-Reply-To: <4B72E051.8090008@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: Anthony Liguori wrote: > On 02/10/2010 10:00 AM, Alexander Graf wrote: > >> On PPC the bitmap is Little Endian. >> >> > > Out of curiousity, why? It seems like an odd interface. > Because on PPC, you usually run PPC32 userspace code on a PPC64 kernel. Unlike with x86, there's no real benefit in using 64 bit userspace. So thanks to the nature of big endianness, that breaks our set_bit helpers, because they assume you're using "long" data types for the bits. While that's no real issue on little endian, since the next int is just the high part of a u64, it messes everything up on ppc. For more details, please just look in the archives on my patches to make it little endian. Alex From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NfFew-0002Sb-AC for qemu-devel@nongnu.org; Wed, 10 Feb 2010 11:43:26 -0500 Received: from [199.232.76.173] (port=54344 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NfFev-0002SJ-Pd for qemu-devel@nongnu.org; Wed, 10 Feb 2010 11:43:25 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NfFes-0002Ig-Ab for qemu-devel@nongnu.org; Wed, 10 Feb 2010 11:43:24 -0500 Received: from cantor.suse.de ([195.135.220.2]:37782 helo=mx1.suse.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NfFer-0002Hq-1V for qemu-devel@nongnu.org; Wed, 10 Feb 2010 11:43:22 -0500 Message-ID: <4B72E224.1090901@suse.de> Date: Wed, 10 Feb 2010 17:43:16 +0100 From: Alexander Graf MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH v2] qemu-kvm: Speed up of the dirty-bitmap-traveling References: <4B728FF9.6010707@lab.ntt.co.jp> <4B72B28E.6010801@redhat.com> <4B72D69D.7050005@codemonkey.ws> <4B72D838.9060603@suse.de> <4B72E051.8090008@codemonkey.ws> In-Reply-To: <4B72E051.8090008@codemonkey.ws> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Anthony Liguori , "kvm@vger.kernel.org" , mtosatti@redhat.com, OHMURA Kei , "qemu-devel@nongnu.org" , Avi Kivity Anthony Liguori wrote: > On 02/10/2010 10:00 AM, Alexander Graf wrote: > >> On PPC the bitmap is Little Endian. >> >> > > Out of curiousity, why? It seems like an odd interface. > Because on PPC, you usually run PPC32 userspace code on a PPC64 kernel. Unlike with x86, there's no real benefit in using 64 bit userspace. So thanks to the nature of big endianness, that breaks our set_bit helpers, because they assume you're using "long" data types for the bits. While that's no real issue on little endian, since the next int is just the high part of a u64, it messes everything up on ppc. For more details, please just look in the archives on my patches to make it little endian. Alex