* Re: OVMF OS boot
2017-07-07 3:40 OVMF OS boot Wu, Jiaxin
@ 2017-07-07 11:40 ` Laszlo Ersek
2017-07-11 3:18 ` Wu, Jiaxin
0 siblings, 1 reply; 3+ messages in thread
From: Laszlo Ersek @ 2017-07-07 11:40 UTC (permalink / raw)
To: Wu, Jiaxin; +Cc: edk2-devel-01
On 07/07/17 05:40, Wu, Jiaxin wrote:
> I'm trying to PXE boot Windows 7 within OVMF. According the README
> under OvmfPkg, I should run the QEMU command with '-vga std' or '-vga
> qxl':
>
> Current capabilities:
>
> ...
>
> * UEFI Linux boots
>
> * UEFI Windows 8 boots
>
> * UEFI Windows 7 & Windows 2008 Server boot (see important notes below!)
>
> ...
> * One of the '-vga std' and '-vga qxl' QEMU options should be used.
> * Only one video mode, 1024x768x32, is supported at OS runtime.
> * The '-vga qxl' QEMU option is recommended. After booting the installed
> guest OS, select the video card in Device Manager, and upgrade its driver
> to the QXL XDDM one. Download location:
> <http://www.spice-space.org/download.html>, Guest | Windows binaries.
> This enables further resolutions at OS runtime, and provides S3
> (suspend/resume) capability.
>
> But after PXE downloaded the install image and run into OS phase(So,
> it's not related to PXE), the QEMU screen is always black, never show
> anything (Both '-vga std' and '-vga qxl').
Windows 7 is a halfway-UEFI OS. It boots on UEFI, yes, but during early
kernel boot, it calls legacy VBE services for initializing video. More
exactly, it locates the VBE services, and runs some of them in a real
mode emulator, such as
<https://en.wikipedia.org/wiki/Virtual_DOS_machine#NTVDM>.
In order to allow Windows 7 to boot on OVMF, we implemented a minimal
set of VBE services, just so Windows 7 can find them and run them in its
real mode emulator. This minimal set of VBE services was determined with
an extremely painful series of trial-and-error, while booting Windows 7
very many times and logging VBE service calls from assembly code.
The reason why these fake services are limited to "-vga std" and "-vga
qxl" is that the VBE services in question are relatively easy to
implement in assembly code for these QEMU video cards.
Please refer to commit 90803342b1b6 ("OvmfPkg: QemuVideoDxe: Int10h stub
for Windows 7 & 2008 (stdvga, QXL)", 2014-05-20).
It is entirely possible that PXE-booting Windows 7 causes Windows 7 to
call some other VBE service that we don't implement. I don't know, I've
never PXE-booted any OS except Linux (and I wouldn't even know what
files to advertize and serve with DHCP / TFTP servers for PXE-booting
Windows.)
The VBE shim in question contains some minimal debug code, of you'd like
to confirm this theory. On Linux, do this:
- navigate to the OvmfPkg/QemuVideoDxe directory
- uncomment the DEBUG %define in "VbeShim.asm"
- run ./VbeShim.sh
- rebuild OVMF like usual
At next boot, the OVMF debug log will contain some simplistic messages
from the VBE shim, when Windows 7 runs the shim in its real mode
emulator.
Honestly though, at this point I doubt we'd like to spend any more
resources on the VBE shim.
> I also tried the PXE boot to windows 10, the bluescreen happened
> during OS phase (Even is not declared to boot win10 in README).
The fact that we don't mention Windows 10 in the README is just an
oversight; 64-bit Windows 10 boots fine on OVMF, at least when booting
it from a disk or a CD-ROM.
(32-bit Windows 8 and Windows 10 break on OVMF, and Microsoft stopped
helping me get to the bottom of it. Please see the BSOD screenshots at
<http://people.redhat.com/~lersek/windows-on-ovmf32/>.)
PXE-booting Windows 10 could place different requirements on the
firmware than booting it from disk or CD-ROM. Again, I don't even know
how to set up a PXE-boot environment for Windows 10.
Unfortunately, I'm not even motivated to research this. Based on:
- my VBE shim development experience with Windows 7,
- my proof that the ACPI interpreter of Windows does not implement
DataTableRegion
<http://mid.mail-archive.com/55F5647C.6030901@redhat.com>,
- and the 32-bit Windows 8/10 boot failure on OVMF (see above),
it's clear that all such research means reverse engineering, and taking
blind shots.
Once Microsoft are willing to provide clear, detailed, and public
*technical* requirements for firmware (not UEFI plugfest presentations),
we can talk.
I assume I could get the instructions from you for setting up DHCP and
TFTP for PXE-booting Windows. You might even be able to tell me what
boot files, and how, should be extracted from the Windows install media
first.
But that is not enough. We need a clear and detailed list of technical
requirements for the firmware, so we can try to satisfy those in OVMF.
And, whenever we run into a BSOD (see again
<http://people.redhat.com/~lersek/windows-on-ovmf32/>), someone with
legal permission to look at the Windows source code has to sit down with
us, and help us debug the failure in a clean-room environment. No more
reverse engineering and trial-and-error, please.
Thanks
Laszlo
^ permalink raw reply [flat|nested] 3+ messages in thread