OVMF OS boot

OVMF OS boot

[Wu, Jiaxin]

Hi Laszlo,



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'). I also tried the PXE boot to windows 10, the bluescreen happened during OS phase (Even is not declared to boot win10 in README).

MyQEMU command is attached as below:
sudo qemu-system-x86_64 \
  -vga std \
  -machine q35 \
  -m 8192 \
  -hda /var/qemuDisk/vd1 \
  -pflash OVMF.fd \
  -global e1000.romfile=""\
  \
  -netdev tap,id=hostnet0,ifname=tap0,script=no,downscript=no \
  -device e1000,netdev=hostnet0

Notes: vd1 is created by: dd if=/dev/zero of=/var/qemuDisk/vd1 seek=1M bs=20480 count=1

Do you know why?

Thanks and Best Regards!
Jiaxin

Re: OVMF OS boot

[Laszlo Ersek]

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

Re: OVMF OS boot

[Wu, Jiaxin]

Hi Laszlo, 

Thanks your detailed analysis/explanation for the windows PXE boot failure. 

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

Yeah. Maybe that's the limitation for us to support the windows PXE boot over OVMF. 

> 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/>.)
> 

Ok. Got your opinion.

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

I agree with the restrictions to enable the windows part PXE boot within QEMU. Fortunately, OVFM has the capability to boot Linux OS via PXE. In current phase, we don't have the mandatory requirement to pass the windows boot OVMF, that's just my quick verification for the OVMF network capability. So, that's fine to me keep it as known issue.

Thanks,
Jiaxin