From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LbmRN-0002uL-83 for qemu-devel@nongnu.org; Mon, 23 Feb 2009 20:50:33 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LbmRK-0002qK-K5 for qemu-devel@nongnu.org; Mon, 23 Feb 2009 20:50:31 -0500 Received: from [199.232.76.173] (port=59179 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LbmRK-0002qH-E4 for qemu-devel@nongnu.org; Mon, 23 Feb 2009 20:50:30 -0500 Received: from mx20.gnu.org ([199.232.41.8]:40923) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LbmRK-0002Fx-1N for qemu-devel@nongnu.org; Mon, 23 Feb 2009 20:50:30 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LbmRE-0005NU-IP for qemu-devel@nongnu.org; Mon, 23 Feb 2009 20:50:24 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [5849] Change MMIO callbacks to use offsets, not absolute addresses. Date: Tue, 24 Feb 2009 01:50:01 +0000 References: <200902240112.28240.paul@codesourcery.com> <49A34CFD.1010506@earthlink.net> In-Reply-To: <49A34CFD.1010506@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902240150.01619.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Robert Reif Cc: qemu-devel@nongnu.org On Tuesday 24 February 2009, Robert Reif wrote: > Paul Brook wrote: > >> 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? > > > > If you're wanting to generate faults from IO devices then getting the > > right physical address is the least of your concerns. First you need to > > figure out how to avoid corrupting the rest of the CPU state. > > The MMU does it so it must be possible. Is it a design issue, performance > issue, just not worth the trouble or no one has really cared up until now? > Please enlighten me further. Is it reasonable to expect it to work someday > or should I just accept that it won't? Bits of both. The TLB is tightly tied into the code generator. Once we get out of the first-level TLB lookup you've not got anywhere near enough information to be able to restore the CPU state. The only way to raise exceptions from within an IO handler is to sync CPU state before every memory access, and you really don't want to do that. This is why the existing unassigned access fault code is busted. In practice you probably want to have the IO handler set a flag somewhere indicating that the access faulted, then add a check to the low-level TLB code to fault in much the same way as for a TLB fault. You can probably avoid slowing down the fast-path ram access case, but you're likely to take a hit on all IO operations. Either way the fault mechanism is largely separate from the device. I'm pretty sure this is consistent with read hardware where the device just indicates that something bad happened, and the CPU figures out everything else itself. Paul