From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NKIn2-0002K7-Rl for qemu-devel@nongnu.org; Mon, 14 Dec 2009 16:49:12 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NKImx-0002Fy-V2 for qemu-devel@nongnu.org; Mon, 14 Dec 2009 16:49:12 -0500 Received: from [199.232.76.173] (port=54211 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NKImx-0002Fn-Nt for qemu-devel@nongnu.org; Mon, 14 Dec 2009 16:49:07 -0500 Received: from mail.gmx.net ([213.165.64.20]:36423) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1NKImw-0008Ex-TP for qemu-devel@nongnu.org; Mon, 14 Dec 2009 16:49:07 -0500 Message-ID: <5563A0E2972D48F59A648CBE0A4F0658@FSCPC> From: "Sebastian Herbszt" References: <20091214141341.GB1360@redhat.com> <4B264AF1.6060802@codemonkey.ws> <7FB8DD1225E54176BCAF5523B6AEA89B@FSCPC> <4B26931E.4000101@codemonkey.ws> <20091214194210.GB6150@redhat.com> <4B269933.3010906@codemonkey.ws> <20091214202019.GF6150@redhat.com> <4B26A0DE.5000304@redhat.com> <20091214203428.GI6150@redhat.com> <4B26A37A.20309@codemonkey.ws> <20091214205015.GB6398@redhat.com> <4B26A892.3040300@codemonkey.ws> In-Reply-To: <4B26A892.3040300@codemonkey.ws> Subject: Re: [Qemu-devel] Re: qdev property bug? Date: Mon, 14 Dec 2009 22:36:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori , "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org, glommer@redhat.com, Kevin O'Connor , Gerd Hoffmann , Alexander Graf Anthony Liguori wrote: > Michael S. Tsirkin wrote: >> On Mon, Dec 14, 2009 at 02:43:38PM -0600, Anthony Liguori wrote: >> >>> Because it can be selected by the user via the menu and because it can >>> be selected at runtime via the boot_set monitor command. >>> >> >> Yes, but it's not like we have nowhere to store them. >> We could shadow ROM when it is actually needed. >> > > I believe the way this works with real BIOSes is that the rom is > initially loaded somewhere outside of the 1M region and it's init is > executed. It's then the rom's job to execute it's initialization. > Afterwards, the bios copies the rom into the 1M region. This is how PMM > works. > > The idea is that while outside of the 1M region, the rom can eliminate > unnecessary code and update it's own header to reflect it's new, > improved code size. It's more like the following (pci 2.2): - enable and map expansion rom bar - find rom and copy to ram (0xC000-0xDFFFF) - disable expansion rom bar - call rom init - rom might resize itself (DDIM) - write protect rom PMM doesn't have (anything?) to do with this and the rom doesn't have to be loaded outside of 1MB. > I don't know whether gpxe will actually reduce it's size as part of this > process so it may not matter. After running the option roms init > vector, the rom must be relocated into the option rom space though so > even this technique is not a solution unless gpxe is able to discard a > lot of bits it doesn't need. gPXE supports DDIM. >>> Also, the comment about "wasting memory" not quite accurate. The memory >>> region in question is only used for roms. If we didn't put roms there, >>> it would go to waste. >>> >> >> Some BIOSes I saw have an option not to use the first 1M for rom >> shadowing :). Seriously as you see we are already >> running out of that 1M. >> > > I think that's just the first phase of rom loading. - Sebastian