From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44060) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SdT8Q-0003bX-NY for qemu-devel@nongnu.org; Sat, 09 Jun 2012 17:23:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SdT8P-0007FX-25 for qemu-devel@nongnu.org; Sat, 09 Jun 2012 17:23:50 -0400 Received: from mail-bk0-f45.google.com ([209.85.214.45]:38850) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SdT8O-0007DO-Ox for qemu-devel@nongnu.org; Sat, 09 Jun 2012 17:23:48 -0400 Received: by bkwj10 with SMTP id j10so2838289bkw.4 for ; Sat, 09 Jun 2012 14:23:46 -0700 (PDT) Date: Sat, 9 Jun 2012 23:23:41 +0200 From: "Edgar E. Iglesias" Message-ID: <20120609212341.GB5062@zapo> References: <1339206871-4706-1-git-send-email-afaerber@suse.de> <20120609152003.GA5062@zapo> <4FD36C5B.6020103@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4FD36C5B.6020103@suse.de> Subject: Re: [Qemu-devel] [PATCH 0/3] xilinx: Speed up the build List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?iso-8859-1?Q?F=E4rber?= Cc: "Peter A. G. Crosthwaite" , qemu-devel@nongnu.org, Alexander Graf , Blue Swirl , Avi Kivity , Paolo Bonzini On Sat, Jun 09, 2012 at 05:31:39PM +0200, Andreas Färber wrote: > Am 09.06.2012 17:20, schrieb Edgar E. Iglesias: > > On Sat, Jun 09, 2012 at 03:54:28AM +0200, Andreas Färber wrote: > >> xilinx_ethlite.c uses tswap32(). Have you ever tested this device to work on > >> microblazeel? I wonder if we could change the device from DEVICE_NATIVE_ENDIAN > >> to DEVICE_BIG_ENDIAN and in place of tswap32() use a bswap32() conditional on > >> HOST_WORDS_BIGENDIAN so that it becomes independent of the target, too? > > > > I don't think that will work. the swap is needed if the endianness of the host > > is different from the one of the target... > > My thinking was: If we can force the device endianness to a known value > then only the host endianness (not the target endianness) matters > because the Memory API will take care of the device endianness. > > The question is: Is the device LE for microblazeel or is it always BE? It can be both LE and BE > > > IIRC, the issue is that the device has a built-in RAM mapped so close to > > the regs that they end up in the same "page". With Avis memory-api maybe it's > > possible to expose this sub-page area as a memory? > > Me and Avi fixed some bugs for subpage areas, it should work in theory > (for TCG/qtest). Not being aware of a MicroBlaze KVM, if it's a RAM > region then we should definitely model it as such. If that's possible, that would get rid of the swaps Cheers