From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NiE6Z-0008VR-9N for qemu-devel@nongnu.org; Thu, 18 Feb 2010 16:40:15 -0500 Received: from [199.232.76.173] (port=40939 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NiE6Y-0008Ud-OS for qemu-devel@nongnu.org; Thu, 18 Feb 2010 16:40:14 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NiE6X-00064G-Ly for qemu-devel@nongnu.org; Thu, 18 Feb 2010 16:40:14 -0500 Received: from mail-pz0-f194.google.com ([209.85.222.194]:33451) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NiE6X-000647-9k for qemu-devel@nongnu.org; Thu, 18 Feb 2010 16:40:13 -0500 Received: by pzk32 with SMTP id 32so568630pzk.4 for ; Thu, 18 Feb 2010 13:40:12 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4B7D51A2.8080704@mvista.com> References: <4B7D51A2.8080704@mvista.com> From: Blue Swirl Date: Thu, 18 Feb 2010 23:39:52 +0200 Message-ID: Subject: Re: [Qemu-devel] How to get 64-bit MMIO? Content-Type: text/plain; charset=UTF-8 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dmitry Antipov Cc: qemu-devel@nongnu.org On Thu, Feb 18, 2010 at 4:41 PM, Dmitry Antipov wrote: > Hello all, > > is there any support for 64-bit MMIO? No, though there has been some discussion about it before which you can find in the archives. 64 bit MMIO would be useful for Sparc32, Sparc64 and Alpha. > I'm trying to emulate 16750-like UART by adopting current 16550A emulation. > The problem is that my (MIPS) hardware is 64-bit, and native software > issues 64-bit load/stores (LD/SD) to talk with all hardware registers, > which are all 64-bit too (for UART case, only 8 lower bits are used, BTW). > As I can see, qemu splits 64-bit access into two 32-bit back-to-back ones, > but this gives catastrophic results if host and guest has different > byte order - i.e. write 0x0000000000000001 to 0x100 gives write 0x00000000 > to 0x100 and 0x10000000 to 0x104 because 64-bit quantities are swapped > within > 32-bit halves. The numbers don't look correct. Anyway, I'd suspect the device should do some byte swapping. Without code it's hard to tell.