From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LAhKI-0005QE-Qp for qemu-devel@nongnu.org; Thu, 11 Dec 2008 03:55:18 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LAhKH-0005Pp-8G for qemu-devel@nongnu.org; Thu, 11 Dec 2008 03:55:18 -0500 Received: from [199.232.76.173] (port=50838 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LAhKH-0005Pm-45 for qemu-devel@nongnu.org; Thu, 11 Dec 2008 03:55:17 -0500 Received: from main.gmane.org ([80.91.229.2]:54314 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LAhKG-0005yp-NT for qemu-devel@nongnu.org; Thu, 11 Dec 2008 03:55:16 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LAhKB-0003bH-K0 for qemu-devel@nongnu.org; Thu, 11 Dec 2008 08:55:11 +0000 Received: from 78.158.192.230 ([78.158.192.230]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 11 Dec 2008 08:55:11 +0000 Received: from vladimir by 78.158.192.230 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 11 Dec 2008 08:55:11 +0000 From: Vladimir Prus Date: Thu, 11 Dec 2008 11:55:04 +0300 Message-ID: References: <200812011859.35859.paul@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Sender: news Subject: [Qemu-devel] Re: MMIO address changes Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Paul Brook wrote: > I've just committed a patch that changes the MMIO callback interface for > devices. Instead of being passed an absolute address these are now passed an > offset from the start[1] of the memory region that was registered. ... > [1] It's actually the offset from the start of the first page of that region. > In practice this difference doesn't matter, and makes the implementation a > lot simpler. This breaks something for me. I have: smc91c111_init(&nd_table[0], (0xb4000000 + 0x01800000 + 0x300) & 0x1fffffff, get_irq(s, 7)); and smc91c111_init presently does: cpu_register_physical_memory(base, 16, iomemtype); and smc emulation promptly dies because an access with address of 0x30e is made, with 0x300 apparently being the offset from the page start, with 0xe being the desired offset. What is the cleanest way to address this? Reverting your change to sms91c111.c works, fwiw. - Volodya