From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38632 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P5QHc-0005Ig-RQ for qemu-devel@nongnu.org; Mon, 11 Oct 2010 17:51:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P5QHb-0003Nh-P9 for qemu-devel@nongnu.org; Mon, 11 Oct 2010 17:51:48 -0400 Received: from terminus.zytor.com ([198.137.202.10]:35427 helo=mail.zytor.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P5QHb-0003Nd-Hy for qemu-devel@nongnu.org; Mon, 11 Oct 2010 17:51:47 -0400 Message-ID: <4CB386EC.2040105@zytor.com> Date: Mon, 11 Oct 2010 14:51:40 -0700 From: "H. Peter Anvin" MIME-Version: 1.0 Subject: Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios References: <20101011101855.GA25030@redhat.com><4CB2E7D0.1010702@redhat.com> <4CB2FDF2.1020705@redhat.com><20101011121634.GB28008@redhat.com> <4CB36A20.5020106@codemonkey.ws><20101011195955.GA5218@redhat.com> <4CB373DD.50307@codemonkey.ws> <4CB37E6E.8010106@zytor.com> <1A62EA512287487ABD27EB8A05A6E1C2@FSCPC> In-Reply-To: <1A62EA512287487ABD27EB8A05A6E1C2@FSCPC> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sebastian Herbszt Cc: Kevin Wolf , seabios@seabios.org, qemu-devel@nongnu.org On 10/11/2010 02:41 PM, Sebastian Herbszt wrote: > H. Peter Anvin wrote: >> On 10/11/2010 01:30 PM, Anthony Liguori wrote: >>> On 10/11/2010 02:59 PM, Gleb Natapov wrote: >>>> No boot rom should do that. extboot wreaks havoc when it is used. >>>> And since virtio is now supported by bios there is no reason to use it. >>> >>> You don't really have a choice. You could be doing hardware passthrough >>> and the ROM on the card may hijack int19. >> >> The BBS standard actually documents how to deal with that -- it pretty >> much works out to "let the card initialize, then see if it mucked with >> int19, and then put int19 back... if we want to run that card, then we >> invoke the int19 that the card set up." > > The BIOS Boot Specification, Version 1.01 from January 11, 1996 seems not to > recommend this: > > 3.4 Legacy IPL Devices > > "Legacy IPL devices will be allowed to take control of the system (via hooking > interrupts) in both Legacy and PnP systems. The Plug and Play BIOS specification > recommends that Legacy devices that hook a bootstrap interrupt such as INT 19h, 18h, > or 13h have the interrupt re-captured by the BIOS. This is not done because grabbing > an interrupt vector back after a device has hooked it can produce unpredictable results. > Further, by allowing the card to take control, the behavior of these Legacy cards will > be the same on both PnP and Legacy machines." > > 6.8 Notes on the POST Process > > "The Plug and Play BIOS Specification says that if a Legacy IPL device's option > ROM captures INT 18h or INT 19h, the BIOS should save this vector and then > restore the original one put there by the BIOS. The BIOS Boot Specification > deviates from this in that these vectors are not recaptured after each Legacy option > ROM returns from initialization. That would be considered unsafe." > Sorry, you're right -- I confused the PNPBIOS spec with the BBS spec (and compounded the error by correctly remembering that BBS overrides PNPBIOS). -hpa