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 <>


Date: 2014-05-13 04:29:08

On 05/12/14 18:21, Mike Maslenkin wrote:
>>>> +  Segment0      = 0;
>>>> +  Segment0Pages = 1;
>>>> +  Status = gBS->AllocatePages (AllocateAddress, EfiReservedMemoryType,
>>>> +                  Segment0Pages, &Segment0);
>>>> +  if (EFI_ERROR (Status)) {
>>>> +    goto RestorePam1;
>>>> +  }
>>> If CSM is enabled, we will fail to allocate, right?
> Allocation at LegacyBiosInstall() function will fail, but no one cares
> about it and MemoryAddress remains uninitialized. This is because uefi
> video driver is being initialized earlier.

In my testing, the order is:
1. LegacyBiosInstall() succeeds
2. QemuVideoDxe fails to allocate, hence gives up on binding the card
3. VideoDxe steps up and binds the card.

You can't reorder #1 with either #2 or #3 (because #1 runs at driver
load time, while #2 and #3 occur during BDS / controller connection;
UEFI driver binding).

You can presumably reorder #2 and #3 with Platform Context Override or
version numbers, but the result would be the same (if VideoDxe gets
there first and claims the card, then QemuVideoDxe won't even get as far
as attempting to allocate page 0).

>> It's not clear what you mean by
>>   If the CSM is enabled
>> In addition, for v2 I'm thinking about changing the memory allocation
>> type (of the page at 0) from EfiReservedMemoryType back to
>> EfiBootServicesCode (same as in your int10-stub branch). The argument
>> goes like this:
>> 1. correctly written UEFI OSes (ie. all except Windows 2008 R2) don't
>> care about the Int10h entry, hence they shouldn't lose a page forever
>> (EfiReservedMemoryType does that)
> Sorry for the noise, but I want to add some notes.
> 1. I'm curious why do you call w2k8 driver buggy.
> According to this document

Allow me to re-indent this:

> * Windows 7, Windows Vista with Service Pack 1 (SP1), Windows Server
>   2008 R2 and Windows Server 2008
>   - Support UEFI 2.0 or later on 64-bit systems. They also support
>     BIOS-based PCs, and UEFI-based PCs running in legacy BIOS-compatibility
>     mode.
>  -  Support on Class 2 systems running in legacy BIOS-compatibility mode
>     by using a CSM, so they can use the legacy BIOS INT10 features.
>  -  Are not supported on Class 3 systems, because these operating
>     systems assume the presence of legacy BIOS INT10 support in the
>     firmware, which is not available in a Class-3 UEFI implementation.
> it is expected behavior. It is also described in "UEFI Support and
> Requirements for Windows Operating Systems" 

I see, thanks for the reference.

OVMF without -D CSM_ENABLE is Class 3 in general ("Computers with UEFI
only"), hence the last paragraph applies ("not supported [...] because
these operating systems assume the presence of legacy BIOS INT10 support
in the firmware"). It's a *documented* bug in Windows Server 2008 R2 then.

In any case, if we cover Int10h with the shim, then that should address
the reason mentioned in the article. (Should be sufficient in the
technical sense.)

>> 2.a. "boot services code" vs. "reserved" makes no difference before
>> ExitBootServices() -- both types protect the IVT from other boot-time
>> allocations.
> Here is my second note. I vote for EfiACPIMemoryNVS.
> It is not clear and violates ACPI spec, but it is true.
> Have you tried to run W7 or W2K8 R2 in SMP mode?

Sure. (Windows Server 2008 R2 SP1.)
- Task Manager | Performance | CPU Usage History displays one chart for
each VCPU I configure (retested now with 2 and 4 VCPUs).
- In addition, in Computer | Properties, System | Processor is listed as
"QEMU Virtual CPU ... (4 processors)".

I'm not sure though how it is relevant.

>> 2.b. Windows 2008 R2 accesses the IVT regardless of the type of the
>> memory allocation that we cover it with. It will certainly not free and
>> then *overwrite* the page at zero (after we've covered it with "boot
>> services code"), because then it couldn't fetch the Int10h entry from it
>> (for emulation).
>> IOW, OSes different from Windows 2008 R2 don't care at all, hence they
>> shouldn't be penalized; and Windows 2008 R2 doesn't overwrite the IVT
>> anyway (at runtime either) before fetching the Int10h entry, so we don't
>> need to protect Win2k8r2 "from itself".
> We need to protect Windows from itself...
> There is a some Microsoft Hyper-V specific, that causes page 0 releasing
> in case of SMP kernel and Hyper-V feature enabled. Windows 6.1 SMP
> kernels do not work even in CSM mode. 

Ah. I see. I haven't experienced this.
- In order to trigger it, I should probably enable some Hyper-V specific
CPU feature on the qemu command line. I don't know what exactly (and how
to) enable.
- I installed the guest from
"en_windows_server_2008_r2_with_sp1_x64_dvd_617601.iso". Maybe a
non-debug build behaves differently.

In any case: if the "SMP plus HyperV" guest configuration doesn't work
even with the CSM enabled, then we absolutely shouldn't try to fix that
config in our VBE shim.


"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