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