qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] IRQ problems under qemu


From: Carl-Daniel Hailfinger
Subject: Re: [Qemu-devel] IRQ problems under qemu
Date: Fri, 05 Dec 2008 19:59:37 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.17) Gecko/20080922 SUSE/1.1.12-0.1 SeaMonkey/1.1.12

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/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]