Re: [edk2] [PATCH] OvmfPkg: QemuVideoDxe: Int10h stub for Windows 2008 R2 SP1 (stdvga, QXL)

Subject: Re: [edk2] [PATCH] OvmfPkg: QemuVideoDxe: Int10h stub for Windows 2008 R2 SP1 (stdvga, QXL)

From: Laszlo Ersek <>

To: David Woodhouse <>

Date: 2014-05-21 23:34:42

On 05/21/14 14:19, David Woodhouse wrote:
> On Tue, 2014-05-13 at 04:54 +0200, Laszlo Ersek wrote:

>> - The specific (possibly accidental, fixable) problem is that using the
>> SeaBIOS CSM plus the CSM infrastructure in edk2 breaks OVMF's S3 resume.
>> I had not set out to track this down because of the other problem (see
>> below).
> Wimp :)

... Yeah :)

>> - The generic / inherent problem with the current SeaBIOS CSM + the edk2
>> CSM infrastructure is that the combination is a nightmare to trace,
>> debug, and modify, for mere mortals. It switches from long mode to real
>> mode and vice versa, and it's impossible to follow unless you know the
>> relevant magic from the Intel SDM from memory.
> Actually I'm not sure that's any more true for CSM than it is for EDK2
> itself. If it doesn't work, most mortals will just give up.
> You did a *lot* of amazing work on enabling S3 support in OVMF. That was
> dark magic, and yes its interaction with CSM will also involve darker
> magic. But once it's fixed, it's fixed. It's largely a solved problem
> and shouldn't *need* to be re-debugged very often. Especially since 'git
> bisect' is such a no-brainer to use once you at least have a point in
> history that *did* work. 

I wish this were true. I don't mean to imply it is not -- I *fear* it
would turn out differently, potentially after we made a support promise
to customers.

>> (Without enabling the CSM in an OVMF build, the option to legacy-boot is
>> lost of course as well, but I expressly don't desire that option. Just
>> boot legacy OSes with pure SeaBIOS; it's easy to choose your firmware in
>> a virtual machine.)
> I don't think I agree that it's easy to choose your firmware.

Ah, by "easy" I meant "easily automatable at some point". There are plans.

> If I'm
> using virt-manager/libvirt under Fedora, how do I do it? I suppose it'd
> be implicit in my choice of operating system? So I might be expected to
> know that selecting "Fedora 20" will use legacy BIOS while "Fedora 21"
> will magically switch me over to UEFI, according to criteria that are
> entirely opaque to me? And if I'm using Ubuntu or something else, the
> choices there might be entirely different?

The libvirt / virt-manager plans (obligatory disclaimer about
forward-looking statements etc etc :)) are about allowing the user to
set the boot firmware in the libvirt domain XML, and to expose that
setting in virt-manager as well. It should be independent of your OS
choice -- for example you could install a SeaBIOS-based Fedora 20 VM and
an OVMF-based Fedora 20 VM.

The /domain/os/loader XML element already presents the possibility of
picking any boot firwmare, but for OVMF it is not sufficient. (Perhaps
the presentation (the XML schema) is, but the implementation (the -bios
qemu flag) is not.) The proposed command line is visible in
 (but it needs
another patch for OVMF that splits the build output in two, a variable
store file and a firmware iamge file, to be mapped consecutively).

In short the plan is to allow VMs to share the fw image on the host
(some VMs would use SeaBIOS, some OVMF, but these would be all backed by
two host-side files in total), and the OVMF-based VMs would each own a
private variable store file in addition. The user-facing tools should
allow the user to pick the firmware.

> Or were you really intending the tools to give the user an explicit
> choice of legacy vs. UEFI rather than depending on the OS? That would
> kind of suck too.

I consider that an advantage. Defaults can be set (OS types already come
with different libvirt defaults), so the user is not forced to choose,
but he/she can opt to.

> Really, I think we should make CSM work and keep it working,

Agreed, but my upstream cycles (too) are finite. When searching for a
good boundary, thinking about "products" is not the worst idea. Feature
creep is dangerous; I like to keep everything at the necessary minimum.

One example: not building the SeaBIOS CSM into the OVMF binary will
likely save one from any latent SeaBIOS bugs (and latent bugs in the
interfacing edk2 infrastructure). Decreasing code size, cutting
project/library dependencies, and limiting responsibility are always good.

(Conversely, choosing SeaBIOS over OVMF will save one from *all* latent
bugs in OVMF / edk2, and the affected guest OS code. If the user doesn't
need the UEFI features, why should I convince him/her to pick OVMF over

> then it's a
> no-brainer for users because things Just Work. Never underestimate the
> collective stupidity of end-users. If we can make it Just Work,
> especially since we're so close already, then I think we should.

I agree, someone should find the time. :) Not sure about "so close"
though; that's only evident in retrospect.

> Which is why I spent the time to enable CSM in the first place, of
> course. Not to mention the fact that having OVMF+CSM as a default
> firmware will serve to accelerate adoption of UEFI in virtual machines,
> and that gives people a *really* easy playground to get involved in EDK2
> source code; fixing bugs and making improvements.

Making OVMF more widely available would probably attract more users, yes
(and if we were forced to provide only one image in some distribution,
then including the CSM could contribute to that). I'm not sure though
how many of the new users would turn into developers (and in particular,
patch reviewers). Remember what you said about the collective stup^W
cluesness of end users! :)

I agree that the CSM build should be kept in working shape, and new
features should consider it as much as possible (and as much as the
developers' workloads allow it). For example, making CSM support a hard
requirement for patch acceptance seems too much (not implying that you
suggested anything like that of course).


"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
edk2-devel mailing list