From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JvzPQ-0006MY-0l for qemu-devel@nongnu.org; Tue, 13 May 2008 14:39:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JvzPN-0006K1-J5 for qemu-devel@nongnu.org; Tue, 13 May 2008 14:39:31 -0400 Received: from [199.232.76.173] (port=36150 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JvzPN-0006Jq-6r for qemu-devel@nongnu.org; Tue, 13 May 2008 14:39:29 -0400 Received: from relay2-v.mail.gandi.net ([217.70.178.76]:43633) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JvzPN-0004Ri-3T for qemu-devel@nongnu.org; Tue, 13 May 2008 14:39:29 -0400 Received: from localhost (mfilter6-v.gandi.net [217.70.178.40]) by relay2-v.mail.gandi.net (Postfix) with ESMTP id CA0E4135AB for ; Tue, 13 May 2008 20:39:27 +0200 (CEST) Received: from relay2-v.mail.gandi.net ([217.70.178.76]) by localhost (mfilter6-v.mgt.gandi.net [217.70.178.40]) (amavisd-new, port 10024) with ESMTP id cSiIz3LVaA7t for ; Tue, 13 May 2008 20:39:25 +0200 (CEST) Received: from [84.102.211.55] (55.211.102-84.rev.gaoland.net [84.102.211.55]) by relay2-v.mail.gandi.net (Postfix) with ESMTP id 2118A135D0 for ; Tue, 13 May 2008 20:39:25 +0200 (CEST) Message-ID: <4829E02A.3090909@bellard.org> Date: Tue, 13 May 2008 20:38:34 +0200 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Re: phys_ram_base, direct access to guest memory References: <18398.33922.132796.510683@mariner.uk.xensource.com> <47DEA908.4040907@qumranet.com> <18398.37844.354219.321675@mariner.uk.xensource.com> <18408.56889.160376.558448@mariner.uk.xensource.com> <20080408184634.GA11492@volta.aurel32.net> <20080505040116.GC15189@hall.aurel32.net> <4829C9C7.2090007@bellard.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 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: qemu-devel@nongnu.org Blue Swirl wrote: > On 5/13/08, Fabrice Bellard wrote: >> Blue Swirl wrote: >> >>> On 5/5/08, Aurelien Jarno wrote: >>> >>>> On Fri, May 02, 2008 at 05:52:07PM +0300, Blue Swirl wrote: >>>> > On 4/8/08, Aurelien Jarno wrote: >>>> > > On Tue, Mar 25, 2008 at 11:12:57AM +0000, Ian Jackson wrote: >>>> > > > I wrote: >>>> > > > > In the attached patch, I remove all the direct uses of >> phys_ram_base >>>> > > > > from hw/pc.c, except for those presently needed to construct >> the >>>> > > > > arguments to the vga init functions. >>>> > > > >>>> > > > Is there something wrong with my patch or the general approach ? >>>> > > >>>> > > >>>> > > It simply doesn't work. After applying it, I get: >>>> > > >>>> > > >>>> > > qemu: fatal: Trying to execute code outside RAM or ROM at >> 0x000a0000 >>>> > >>>> > I fixed the bug in the patch, cpu_physical_memory_write_rom must be >>>> > used instead of cpu_physical_memory_write. I also made the same >>>> > changes to Sparc32/64, they run fine. Does this version work for PC >>>> > targets? >>>> >>>> >>>> Unfortunately the problem is still there, with the same error message. >>>> >>> There were two additional problems, the offset was incorrect and the >>> memory was written before it was mapped. This version seems to work. >>> >>> Any objections? May I commit this version? >>> >> OK for the kernel loading, but not for the BIOS loading : there is no >> reason all the BIOS is mapped at a particular physical address (because this >> address is selectable by specific chipset bits), so it must really be loaded >> at ram addresses, not at physical addresses. >> >> IMHO, it still makes sense to allow loading of data at a particular ram >> address. > > I removed the BIOS loading parts. But is it possible to adjust VGA > BIOS and option ROM addresses by chipset? > [...] Yes. At least part of the BIOS can be replaced by RAM on a real PC (a subset is implement is piix_pci.c). Generically speaking, loading the content of a ROM/flash at a physical address is almost always a bug or the indication that the corresponding hardware model is greatly simplified. There must be generic function to load data at a given ram address. If you want to avoid the use of phys_ram_base, then you can add a specific memcpy function similar to the one for the physical memory. But it is not a good idea at all to suppress the access to the RAM memory ! Regards, Fabrice.