From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LblnU-0001MD-Tp for qemu-devel@nongnu.org; Mon, 23 Feb 2009 20:09:20 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LblnU-0001L7-2O for qemu-devel@nongnu.org; Mon, 23 Feb 2009 20:09:20 -0500 Received: from [199.232.76.173] (port=39195 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LblnT-0001Kz-VG for qemu-devel@nongnu.org; Mon, 23 Feb 2009 20:09:20 -0500 Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]:41412) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LblnT-0004dM-Ie for qemu-devel@nongnu.org; Mon, 23 Feb 2009 20:09:19 -0500 Message-ID: <49A347DD.3030906@earthlink.net> Date: Mon, 23 Feb 2009 20:05:33 -0500 From: Robert Reif MIME-Version: 1.0 Subject: Re: [Qemu-devel] [5849] Change MMIO callbacks to use offsets, not absolute addresses. References: <200902231704.28500.paul@codesourcery.com> <49A33A81.1070800@earthlink.net> <200902240030.29683.paul@codesourcery.com> In-Reply-To: <200902240030.29683.paul@codesourcery.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org Paul Brook wrote: >> Sparc devices are passed in their physical addresses. They are >> currently hard wired >> because there is no proper bus/slot layer and only on-broad devices are >> implemented >> anyway. However each system may have the same hardware located at >> different locations >> so this may not be typical QEMU behavior. Real hardware deals with real >> addresses. >> > > Oh real hardware address decoding is typically implemented as chip selects in > the host bridge, routing tables in the switch fabric, and/or having > individual devices do address decoding and claiming transactions on a shared > bus. Modelling full per-device address decoding simply isn't feasible, we > have to use additional knowledge (e.g. PCI BARs or fixed address fanges) to > perform that decoding at a higher level. > > The layers above the device emulation must be responsible for generating the the physical address appropriately. This is looking at the problem from a sparc perspective. Sparc hardware is very fault happy and will generate a fault if you look at it funny. This isn't an issue when running a fully debugged OS but limits QEMU's usefulness as a OS development platform. The open boot self tests do strange and unimplemented things and I would like to see more of that work in the future. The same applies to more than the currently supported OSs. I would rather have the hardware emulation work properly and run any OS than the current approach of trying a specific OS and hardware configuration and fixing what breaks. All I want is QEMU to be a better product. How do you propose having the hardware drivers generate meaningful and timely faults when an improper access is performed so it behaves like real low level software expects the hardware to behave? A device could generate a fault and pass the offset up to a higher layer that has knowledge of the real physical address but that currently doesn't exist.