From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NKI6o-0004cc-Af for qemu-devel@nongnu.org; Mon, 14 Dec 2009 16:05:34 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NKI6j-0004WO-9j for qemu-devel@nongnu.org; Mon, 14 Dec 2009 16:05:33 -0500 Received: from [199.232.76.173] (port=46754 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NKI6j-0004WD-3V for qemu-devel@nongnu.org; Mon, 14 Dec 2009 16:05:29 -0500 Received: from mail-yw0-f171.google.com ([209.85.211.171]:52823) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NKI6i-0003Vn-EM for qemu-devel@nongnu.org; Mon, 14 Dec 2009 16:05:28 -0500 Received: by ywh1 with SMTP id 1so3201337ywh.18 for ; Mon, 14 Dec 2009 13:05:27 -0800 (PST) Message-ID: <4B26A892.3040300@codemonkey.ws> Date: Mon, 14 Dec 2009 15:05:22 -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> In-Reply-To: <20091214205015.GB6398@redhat.com> 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: "Michael S. Tsirkin" Cc: glommer@redhat.com, qemu-devel@nongnu.org, Alexander Graf , Kevin O'Connor , Gerd Hoffmann , Sebastian Herbszt 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. 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. >> 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. >> Currently, the only roms we load are pxe roms or things specified by >> -option-rom. You could certainly argue that making -option-rom higher >> priority than implicit pxe roms is valuable but removing the pxe roms >> really serves no purpose. >> >> Regards, >> >> Anthony Liguori >> > > I am concerned about management. User selects "PXE support" when > creating VM, and creationg succeeds, but in fact PXE can not work > because we can not shadow the ROM. > > Sounds bad. If device creation failed, > user would get feedback when it is expected. > It's unfortunately much more complicated than this :-/ Ignore the case of one nic, that should Just Work today. If you have two nics, even if we are able to load both roms, we have no way of communicating to the bios that we want to use one BEV device vs. another. That means if you have two nics that are both capable of pxe booting, '-boot n' really cannot be used to determine which one actually gets to pxe boot. We'll have the same problem with BCV based extboot. We really need to improve -boot to support things other than the concept of "first disk" and "first nic". That's why I'm a fan of the intermediate solution of just stopping loading roms when we run out of room. It's just as well defined behavior as we have even if we could load more roms. Regards, Anthony Liguori