From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55180) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTTop-0005PT-1f for qemu-devel@nongnu.org; Thu, 05 Mar 2015 06:19:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YTTol-0003eK-2i for qemu-devel@nongnu.org; Thu, 05 Mar 2015 06:19:55 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55029) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTTok-0003e5-Po for qemu-devel@nongnu.org; Thu, 05 Mar 2015 06:19:50 -0500 Message-ID: <1425554261.12745.68.camel@nilsson.home.kraxel.org> From: Gerd Hoffmann Date: Thu, 05 Mar 2015 12:17:41 +0100 In-Reply-To: References: <97fd6e025b9dfa941ea0d7677b52f66c@mail.shatteredsilicon.net> <1425475231.8389.63.camel@nilsson.home.kraxel.org> <9779520a9ba5544750f4eb570ce3bf8c@mail.shatteredsilicon.net> <1425542908.12745.22.camel@nilsson.home.kraxel.org> <1425552166.12745.57.camel@nilsson.home.kraxel.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] QEMU etc/e820 and fw_cfg List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gordan Bobic Cc: qemu-devel@nongnu.org Hi, > > Add "e820_add_entry(start, size, E820_RESERVED)" calls in qemu. > > Could you please point me at the correct file/function to add > the relevant block into? There are already calls (in hw/i386/pc.c I think) already, adding entries for RAM. I'd try to place the code nearby, especially as you might change the ram code too to avoid ram being allocated for the reserved areas. > > Also make sure the firmware doesn't use those ranges, which may need > > firmware patching. At least seabios should happily add those > > reservations to the e820 map, but will not look at them otherwise, so > > you could end up with pci bars being mapped within the reserved > > regions. > > Are you saying that seabios will find reserved areas in the e820 > map and despite that map a BAR into a reserved block? It just copies over the entries, from qemu firmware interface to guest ram, so the OS (linux/windows/whatever) can see the reservations. > That's pretty > broken... There was no need so far to implement something more advanced in seabios. Another option is using coreboot as firmware. coreboot resource management is alot more powerful. It has to run on real hardware not only qemu, so it needs to be able to deal with all sorts of quirks. It should handle this just fine and place all pci bars outside the reservations. > > The linux kernel might fix it up at boot though. > > If you mean inside the VM, Linux-on-Linux isn't my intended use case, > though. Might be useful for testing though as you can easily check stuff in the kernel boot log and /proc/iomem. cheers, Gerd