qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Kevin O'Connor <kevin@koconnor.net>
Cc: seabios@seabios.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [SeaBIOS] [PATCH 5/5] [wip] sercon: initial split-output implementation
Date: Tue, 27 Sep 2016 14:00:08 +0200	[thread overview]
Message-ID: <1474977608.26376.22.camel@redhat.com> (raw)
In-Reply-To: <20160715143517.GA30705@morn.lan>

On Fr, 2016-07-15 at 10:35 -0400, Kevin O'Connor wrote:
> On Fri, Jul 15, 2016 at 01:49:49PM +0200, Gerd Hoffmann wrote:
> > > Finally, one high level observation is that we know there are a number
> > > of quirks in various vgabios emulators.  For example, we know some
> > > emulators don't handle certain 32bit instructions when in 16bit mode
> > > (hence scripts/vgafixup.py), we know some versions of Windows use an
> > > emulator that doesn't like some stack relative instructions (hence the
> > > vgabios is compiled without -fomit-frame-pointer), and we know Windows
> > > Vista doesn't like the extra stack in high ram (the skifree bug).  Any
> > > thoughts on what happens with these quirks if the main seabios code
> > > hooks int10?
> > 
> > Good question.  Do the emulators (both win, xorg) use the int10 vector
> > set by seabios in the first place?  Or go they load the vgabios and run
> > it, including the initialization, and use whatever entry point the init
> > code sets up?  I suspect it is the latter.  But needs investigation and
> > testing.
> 
> I think they just call the existing int10 handler.  In general, it's
> not safe to rerun the vga init code.  Also, if they did run the init
> it would lead to extra copies of the SeaVGABIOS version banners in the
> debug logs, which I don't recall seeing.

Finally found the time to continue with this and ran a bunch of tests.
RHEL-5 (known to be affected by x86emu issue) continues to work fine.
Xorg server log looks like it goes scan memory for the vgabios instead
of depending on the int10 vector:

(II) VESA(0): initializing int10
(II) VESA(0): Primary V_BIOS segment is: 0xc000
(II) VESA(0): VESA BIOS detected
(II) VESA(0): VESA VBE Version 3.0
(II) VESA(0): VESA VBE Total Mem: 16384 kB
(II) VESA(0): VESA VBE OEM: SeaBIOS VBE(C) 2011
(II) VESA(0): VESA VBE OEM Software Rev: 0.0
(II) VESA(0): VESA VBE OEM Vendor: SeaBIOS Developers
(II) VESA(0): VESA VBE OEM Product: SeaBIOS VBE Adapter
(II) VESA(0): VESA VBE OEM Product Rev: Rev. 1

Running tests with win7 doesn't show any problems too, so I suspect they
are basically doing the same.

Given these results I think I'll stick to the current approach of
integrating this directly into seabios (instead of creating a
sgabios-like rom using the seavgabios sources).

cheers,
  Gerd

  parent reply	other threads:[~2016-09-27 12:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-14  8:52 [Qemu-devel] [PATCH 0/5] serial console support Gerd Hoffmann
2016-07-14  8:52 ` [Qemu-devel] [PATCH 1/5] std: add cp437 to unicode map Gerd Hoffmann
2016-07-14 16:17   ` [Qemu-devel] [SeaBIOS] " Kevin O'Connor
2016-07-14  8:52 ` [Qemu-devel] [PATCH 2/5] kbd: make enqueue_key public, add ascii_to_keycode Gerd Hoffmann
2016-07-14  8:53 ` [Qemu-devel] [PATCH 3/5] paravirt: read QEMU_CFG_NOGRAPHIC, store in etc/sercon-enable romfile Gerd Hoffmann
2016-07-14  8:53 ` [Qemu-devel] [PATCH 4/5] add serial console support Gerd Hoffmann
2016-07-14  8:53 ` [Qemu-devel] [PATCH 5/5] [wip] sercon: initial split-output implementation Gerd Hoffmann
2016-07-14 16:15   ` [Qemu-devel] [SeaBIOS] " Kevin O'Connor
2016-07-15 11:49     ` Gerd Hoffmann
2016-07-15 14:35       ` Kevin O'Connor
2016-08-08 13:14         ` Gerd Hoffmann
2016-09-27 12:00         ` Gerd Hoffmann [this message]
2016-10-04  3:03           ` Kevin O'Connor
2016-10-04  8:49             ` Gerd Hoffmann
2016-10-04  9:21               ` Igor Mammedov
2016-10-13  7:17                 ` Gerd Hoffmann
2016-10-13  8:09                   ` Igor Mammedov

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=1474977608.26376.22.camel@redhat.com \
    --to=kraxel@redhat.com \
    --cc=kevin@koconnor.net \
    --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 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).