From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id BFCFE21CE73F0 for ; Fri, 7 Jul 2017 04:38:50 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BFB72A4F81; Fri, 7 Jul 2017 11:40:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com BFB72A4F81 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com BFB72A4F81 Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-21.phx2.redhat.com [10.3.116.21]) by smtp.corp.redhat.com (Postfix) with ESMTP id 02A596031C; Fri, 7 Jul 2017 11:40:30 +0000 (UTC) To: "Wu, Jiaxin" Cc: edk2-devel-01 References: <895558F6EA4E3B41AC93A00D163B7274162E37E7@SHSMSX103.ccr.corp.intel.com> From: Laszlo Ersek Message-ID: Date: Fri, 7 Jul 2017 13:40:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <895558F6EA4E3B41AC93A00D163B7274162E37E7@SHSMSX103.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 07 Jul 2017 11:40:31 +0000 (UTC) Subject: Re: OVMF OS boot X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 11:38:51 -0000 Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: > , 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 . 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 .) 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 , - 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 ), 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