From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L8ftt-0006WD-K5 for qemu-devel@nongnu.org; Fri, 05 Dec 2008 13:59:41 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L8fts-0006Vt-Pp for qemu-devel@nongnu.org; Fri, 05 Dec 2008 13:59:41 -0500 Received: from [199.232.76.173] (port=40473 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L8fts-0006Vq-Gq for qemu-devel@nongnu.org; Fri, 05 Dec 2008 13:59:40 -0500 Received: from mail.gmx.net ([213.165.64.20]:46172) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1L8ftr-0003Bx-TY for qemu-devel@nongnu.org; Fri, 05 Dec 2008 13:59:40 -0500 Message-ID: <49397A19.3080301@gmx.net> Date: Fri, 05 Dec 2008 19:59:37 +0100 From: Carl-Daniel Hailfinger MIME-Version: 1.0 Subject: Re: [Qemu-devel] IRQ problems under qemu References: <4938E7C9.8090107@dbservice.com> In-Reply-To: <4938E7C9.8090107@dbservice.com> 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 Cc: coreboot@coreboot.org On 05.12.2008 09:35, Tomas Carnecky wrote: > When I tried to run coreboot under qemu, I was at first positively > surprised how well the things worked. The BIOS + linux kernel payload > booted in no time! But when I then tried to set up networking, I > couldn't get that to work. Somehow the linux kernel couldn't locate > the interrupts of the NIC. After some digging I found out that > coreboot doesn't provide ACPI tables and instead uses PCI IRQ table (I > had to extract this table from a running qemu system using the getpir > utility and then copy it to coreboot, if you want that patch, I can > send that too). Coreboot copies this table at runtime into memory at > 0xf0000. Apparently 0xf0000-0xfffff is part of the ISA BIOS, and qemu > marks this range as read-only. > The attached patch for qemu fixes that and also cleans up some of the > memory initialization. Instead of marking the ISA BIOS as read-only, > it copies that part from the BIOS image into the appropriate place (at > 0xf0000-0xfffff) and leaves the memory as read-write. I believe that works around the problem you're seeing, but in theory the BIOS/firmware should be able to tell Qemu when it wants to enable RAM or ROM mapping in that area. Qemu early adress map (RAM vs. ROM) for x86 is unrealistic anyway because it assumes RAM is available from the start and RAM/ROM designation of a given area will not change. The quirk you're hitting is just another aspect of that problem. Regards, Carl-Daniel -- http://www.hailfinger.org/