From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L7Dzu-0007rY-2h for qemu-devel@nongnu.org; Mon, 01 Dec 2008 13:59:54 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L7Dzt-0007qd-8r for qemu-devel@nongnu.org; Mon, 01 Dec 2008 13:59:53 -0500 Received: from [199.232.76.173] (port=33996 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L7Dzt-0007qU-5O for qemu-devel@nongnu.org; Mon, 01 Dec 2008 13:59:53 -0500 Received: from mx20.gnu.org ([199.232.41.8]:61147) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1L7Dzs-00023e-OG for qemu-devel@nongnu.org; Mon, 01 Dec 2008 13:59:52 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L7Dzr-0005HA-1C for qemu-devel@nongnu.org; Mon, 01 Dec 2008 13:59:51 -0500 From: Paul Brook Date: Mon, 1 Dec 2008 18:59:35 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812011859.35859.paul@codesourcery.com> Subject: [Qemu-devel] 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 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. By itself this change has fairly neutral benefit, it just moves logic about. However it makes subsequent dynamic board configuration bits nicer, and is a step towards a proper bus level API. Most of the groundwork for this is already there, from my earlier changes to separate ram and MMIO addresses TLB handling. The main notable change it that the PhysPageDesc structure is not bigger. This isn't ideal, however l2_phys_map needs to go away anyway, so I'm not really worried about this. Some devices register their memory regions in multiple segments. To facilitate this I have added cpu_register_physical_memory_offset. Most of the remaining changes are fairly mechanical tweaks to fix devices that explicitly compensated for the absolute address. Many devices are untouched because they ignore the high bits of the address. I've tried to be fairly thorough with the changes, and tested what I can. However it's possible I missed or broke something, so please test your favourite targets. Paul [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.