All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Sebastian Herbszt <herbszt@gmx.de>
Cc: Kevin Wolf <kwolf@redhat.com>,
	seabios@seabios.org, qemu-devel@nongnu.org
Subject: Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios
Date: Mon, 11 Oct 2010 14:51:40 -0700	[thread overview]
Message-ID: <4CB386EC.2040105@zytor.com> (raw)
In-Reply-To: <1A62EA512287487ABD27EB8A05A6E1C2@FSCPC>

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

  reply	other threads:[~2010-10-11 21:51 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-11 10:18 [Qemu-devel] [RFC] Passing boot order from qemu to seabios Gleb Natapov
2010-10-11 10:32 ` Kevin Wolf
2010-10-11 10:43   ` Gleb Natapov
2010-10-11 11:01     ` Kevin Wolf
2010-10-11 12:07   ` Gerd Hoffmann
2010-10-11 12:16     ` Gleb Natapov
2010-10-11 19:48       ` [SeaBIOS] " Anthony Liguori
2010-10-11 19:59         ` Gleb Natapov
2010-10-11 20:30           ` Anthony Liguori
2010-10-11 20:36             ` Gleb Natapov
2010-10-11 20:50               ` Anthony Liguori
2010-10-11 21:14                 ` Gleb Natapov
2010-10-11 21:15             ` H. Peter Anvin
2010-10-11 21:41               ` Sebastian Herbszt
2010-10-11 21:51                 ` H. Peter Anvin [this message]
2010-10-12  8:01               ` Gleb Natapov
2010-10-12 16:33                 ` H. Peter Anvin
2010-10-12 16:56                   ` Gleb Natapov
2010-10-12 17:35                     ` H. Peter Anvin
2010-10-12 17:41                       ` Gleb Natapov
2010-10-12 17:45                         ` H. Peter Anvin
2010-10-12 19:06                           ` Gleb Natapov
2010-10-13 19:17                             ` H. Peter Anvin
2010-10-13 20:00                               ` H. Peter Anvin
2010-10-13 20:22                                 ` H. Peter Anvin
2010-10-11 19:51     ` Anthony Liguori
2010-10-11 20:02       ` Gleb Natapov
2010-10-11 20:18       ` [SeaBIOS] " H. Peter Anvin
2010-10-11 11:16 ` Bernhard Kohl
2010-10-11 12:08   ` Gleb Natapov
2010-10-11 23:33     ` [SeaBIOS] " Kevin O'Connor
2010-10-11 12:48   ` Stefan Hajnoczi
2010-10-11 14:29     ` Gleb Natapov
2010-10-11 15:52       ` Stefan Hajnoczi
2010-10-11 16:04         ` Gleb Natapov
2010-10-11 17:01         ` Anthony Liguori
2010-10-11 17:04           ` Gleb Natapov
2010-10-11 23:16             ` [SeaBIOS] " Kevin O'Connor
2010-10-12  8:44             ` Stefan Hajnoczi
2010-10-11 15:09 ` [Qemu-devel] Re: [SeaBIOS] " Avi Kivity
2010-10-11 15:39   ` Gleb Natapov
2010-10-11 15:42     ` Avi Kivity
2010-10-11 15:52       ` Gleb Natapov
2010-10-12  0:08 ` Kevin O'Connor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CB386EC.2040105@zytor.com \
    --to=hpa@zytor.com \
    --cc=herbszt@gmx.de \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=seabios@seabios.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.