Re: [edk2] OVMF VGA resume status (was: [PATCH 00/22] S3 suspend/resume for OVMF)

Subject: Re: [edk2] OVMF VGA resume status (was: [PATCH 00/22] S3 suspend/resume for OVMF)

From: Jordan Justen <>

To: "" <>

Date: 2013-12-12 17:47:22

On Thu, Dec 12, 2013 at 12:44 AM, Gerd Hoffmann  wrote:
>   Hi,
>> (1) When booting Linux with OVMF's GOP (doesn't matter with which video
>> card), the first driver grabbing the card is the efifb driver. This is
>> reported in dmesg as:
>> [    0.891094] efifb: probing for efifb
>> [    0.896161] efifb: framebuffer at 0xa4000000, mapped to
>>                0xffffc90000780000, using 1876k, total 1875k
>> [    0.906944] efifb: mode is 800x600x32, linelength=3200, pages=1
>> [    0.913958] efifb: scrolling: redraw
>> [    0.918211] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
>> [    0.926951] Console: switching to colour frame buffer device 100x37
>> [    0.935261] fb0: EFI VGA frame buffer device
>> However, soon after, a card-specific FB driver comes along, and kicks
>> off the efifb driver.
> Yep, efifb is basically the vesafb aequivalent in the efi world.
> BTW: Recent kernels seem to attempt unify them (and other
> firmware-initialized framebuffers) as simplefb (and simpledrm), so if
> you see them pop up somewhere you know what it is ;)
>> (2) So, let's consider four cases:
>> - QXL with qxldrmfb
>> - QXL with efifb (qxldrmfb blacklisted)
>> - Cirrus with cirrusdrmfb
>> - Cirrus with efifb (cirrusdrmfb blacklisted)
> There are two more players:
>  * cirrusfb (CONFIG_FB_CIRRUS, not enabled by default in fedora
>    kernels).  drm is the way to go though.  But maybe worth testing S3
>    and maybe borrow code to handle suspend/resume in drm/cirrus driver.
>  *
>    [ need to bug airlied again about getting it merged ... ]
>> (2a) QXL with qxldrmfb
>> One nit that I have is that the character console performance is really
>> sluggish and the screen updates are ugly. But that's my fault, because I
>> was too lazy to set up a SPICE display, and QXL is very likely not
>> optimized for VNC (which is what I used).
> Visible with spice too.  Probably something in the guest driver.
>> (2c) Cirrus with cirrusdrmfb
>> I wrote an OVMF bootscript patch (more about it later), and the screen
>> started to do *something* after resume, but it presented the typical
>> sheared image of the stride being wrong.
> Sounds like card running with efifb modesetting but cirrus kernel driver
> thinks its own, different config is active.
>> (2d) Cirrus with efifb (cirrusdrmfb blacklisted)
>> This setup seems to rule out X11 at once (probably not a popular
>> setup...),
> X11 can run on top of a framebuffer device just fine.  Make sure you
> have xorg-x11-drv-fbdev installed.
>> Maybe the guest could write a boot script via SMM, but resume support in
>> a guest driver is probably better.
> Yes, we should fix drm/cirrus.
> Did you try cirrus S3 with seabios btw?

Good question. Before this thread, I would have expected that seabios
would not try to restore this on resume.

And a meaner question... What happens with windows?

Normally we would expect the OS graphics driver to restore this. But
in this case, I guess we could argue that the cirrus device closely
associated with x86 QEMU. It would essentially be a platform hack for
a device where the OS drivers were known to be inadequate. (Obviously
the more ideal fix is in the OS/driver.)


Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
edk2-devel mailing list