From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NKIq3-0003Z6-Jg for qemu-devel@nongnu.org; Mon, 14 Dec 2009 16:52:19 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NKIpy-0003Wg-Dt for qemu-devel@nongnu.org; Mon, 14 Dec 2009 16:52:18 -0500 Received: from [199.232.76.173] (port=50429 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NKIpy-0003Wa-8a for qemu-devel@nongnu.org; Mon, 14 Dec 2009 16:52:14 -0500 Received: from mail-gx0-f223.google.com ([209.85.217.223]:62217) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NKIpy-0008Pl-1C for qemu-devel@nongnu.org; Mon, 14 Dec 2009 16:52:14 -0500 Received: by gxk23 with SMTP id 23so4902693gxk.2 for ; Mon, 14 Dec 2009 13:52:13 -0800 (PST) Message-ID: <4B26B389.2080708@codemonkey.ws> Date: Mon, 14 Dec 2009 15:52:09 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: qdev property bug? 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> <5563A0E2972D48F59A648CBE0A4F0658@FSCPC> In-Reply-To: <5563A0E2972D48F59A648CBE0A4F0658@FSCPC> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sebastian Herbszt Cc: "Michael S. Tsirkin" , glommer@redhat.com, qemu-devel@nongnu.org, Alexander Graf , Kevin O'Connor , Gerd Hoffmann Sebastian Herbszt wrote: > 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. Well PMM is used to do the resizing. But it sounds like the problem is that we should not be loading the roms into the rom space. Instead, seabios should be mapping them into that space, running the rom init, then moving to the next one. I suspect we need to either need to implement the proper pci interface for seabios to do this or we need to provide a pv channel. Regards, Anthony Liguori