qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/3] switch to seavgabios


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [PATCH 0/3] switch to seavgabios
Date: Wed, 18 Apr 2012 15:07:35 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120307 Thunderbird/10.0.3

  Hi,

[ adding seabios list to Cc:, topic is the missing vesa 2.0 protected
  mode interface in seavgabios ]

>> Pointer?
>> I'd like to have a test case which breaks with the new vgabios.
> 
> We talked with malc briefly on irc yesterday, and this is what
> he gave me:
> 
> http://cvs.savannah.gnu.org/viewvc/vgabios/vbe.c?root=vgabios&r1=1.47&r2=1.48
> 
> this is not the test case but the missing support he's referring to.
> 
> It appears the patch implements just 2 functions which both just does
> int10,

It isn't that simple.  Just invoking int10 from protected mode isn't
guaranteed to have the desired effect.  It certainly wouldn't work for
linux vesafb panning.  It might work for dos extenders, they might have
the idt entry for int10 and other bios interrupts setup accordingly to
do a real-mode -> bios call -> protected mode transition to simplify
porting dos code to the 32bit extender.  But even for that use case it
is IMHO pointless as the reason to have a 32bit interface is to avoid
the expensive real mode switch in the first place ...

The code has been changed later on, for good reasons, see
http://git.qemu.org/?p=vgabios.git;a=commitdiff;h=72c270d8091fb0f09e8291cc0e7154b075b921a9

> so should be easy to implement in seabios,

seavgabios has no 32bit code at all at the moment.  vesa pmi didn't seem
to be important enougth to change it.

seabios is a 16/32bit hybrid with some code being compiled twice for
both modes; dunno how reusable the seabios infrastructure is.  Unlike
seabios seavgabios has no fixed load address, which makes things a bit
more complicated when it comes to global variables I think.

At least for the bochs interface this wouldn't be a showstopper though.
Instead of using global variables to figure stuff like the active video
mode we can just read the bits we need from the bochs device registers.
 Costs some extra vmexits of course, and we wouldn't have code sharing
for 16+32bit paths.

cheers,
  Gerd



reply via email to

[Prev in Thread] Current Thread [Next in Thread]