From: Kevin O'Connor <kevin@koconnor.net>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, Sebastian Herbszt <herbszt@gmx.de>
Subject: [Qemu-devel] Re: Seabios dislikes -M isapc
Date: Mon, 8 Feb 2010 19:51:10 -0500 [thread overview]
Message-ID: <20100209005110.GC18282@morn.localdomain> (raw)
In-Reply-To: <4B70615D.2080406@siemens.com>
On Mon, Feb 08, 2010 at 08:09:17PM +0100, Jan Kiszka wrote:
> Sebastian Herbszt wrote:
> > Jan Kiszka wrote:
> >> Hi,
> >>
> >> Seabios seems to have some assumptions built in that break when -M isapc
> >> is selected. Is this supposed to work or is isapc about to die?
> >
> > SeaBIOS doesn't POST if the F-segment is not writeable [1]. A possible, but IMO
> > wrong fix was posted on the list [2].
> >
> > [1] http://lists.gnu.org/archive/html/qemu-devel/2009-11/msg01188.html
> > [2] http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg00445.html
> >
>
> Indeed, [2] makes it work again.
>
> But taking away IO_MEM_ROM really looks like a lazy workaround. I don't
> know how much Seabios needs to write - can't it use normal RAM for this?
Handling a read-only f-segment in SeaBIOS would result in significant
code complexity, and some features (like smbios) couldn't be made to
work at all.
I believe it would be far simpler to add a mechanism for
locking/unlocking the f-segment in non-pci mode than it would be to
make seabios work with a read-only f-segment.
Finally, in the normal pci enabled case, both SeaBIOS and bochs bios
will lock the f-segment regardless of how it starts. So, the patch at
[1] is pretty harmless and it leads to an overall simplification.
-Kevin
next prev parent reply other threads:[~2010-02-09 0:51 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-08 10:17 [Qemu-devel] Seabios dislikes -M isapc Jan Kiszka
2010-02-08 18:38 ` [Qemu-devel] " Sebastian Herbszt
2010-02-08 19:09 ` Jan Kiszka
2010-02-09 0:51 ` Kevin O'Connor [this message]
2010-02-09 20:47 ` Sebastian Herbszt
2010-02-09 19:45 ` [Qemu-devel] " Andreas Färber
2010-02-09 19:50 ` Anthony Liguori
2010-02-09 20:36 ` Natalia Portillo
2010-02-09 21:05 ` Anthony Liguori
2010-02-09 21:36 ` Natalia Portillo
2010-02-09 21:41 ` Anthony Liguori
2010-02-09 22:41 ` malc
2010-02-09 23:25 ` Aurelien Jarno
2010-02-09 23:28 ` malc
2010-02-10 0:00 ` Anthony Liguori
2010-02-10 0:27 ` malc
2010-02-10 0:31 ` Anthony Liguori
2010-02-11 23:51 ` Jamie Lokier
2010-02-12 2:44 ` Anthony Liguori
2010-02-09 23:27 ` Natalia Portillo
2010-02-09 23:30 ` malc
2010-02-09 22:37 ` malc
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=20100209005110.GC18282@morn.localdomain \
--to=kevin@koconnor.net \
--cc=herbszt@gmx.de \
--cc=jan.kiszka@siemens.com \
--cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).