From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (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 781AB21D147A9 for ; Mon, 10 Jul 2017 20:16:44 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jul 2017 20:18:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,344,1496127600"; d="scan'208";a="109801247" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga002.jf.intel.com with ESMTP; 10 Jul 2017 20:18:29 -0700 Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 10 Jul 2017 20:18:29 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by FMSMSX154.amr.corp.intel.com (10.18.116.70) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 10 Jul 2017 20:18:28 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.116]) by shsmsx102.ccr.corp.intel.com ([169.254.2.146]) with mapi id 14.03.0319.002; Tue, 11 Jul 2017 11:18:26 +0800 From: "Wu, Jiaxin" To: Laszlo Ersek CC: edk2-devel-01 Thread-Topic: OVMF OS boot Thread-Index: AdL20ngK1gDTC489RhydpUjEfUQaPgAAE7+AAMeJoFA= Date: Tue, 11 Jul 2017 03:18:26 +0000 Message-ID: <895558F6EA4E3B41AC93A00D163B7274162E6EA3@SHSMSX103.ccr.corp.intel.com> References: <895558F6EA4E3B41AC93A00D163B7274162E37E7@SHSMSX103.ccr.corp.intel.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZGRiNmNiYzctNzQyOS00OTI2LTk2YjAtODMwMDQ0ZTY1MWViIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IkoxOCtLU1BUbzBrZnRFeTZ4KzN2ckJaUmZ4MitOcHRoVmNHYlwvRFQrMW84PSJ9 x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 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: Tue, 11 Jul 2017 03:16:44 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Laszlo,=20 Thanks your detailed analysis/explanation for the windows PXE boot failure.= =20 >=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.) > Yeah. Maybe that's the limitation for us to support the windows PXE boot ov= er OVMF.=20 > 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. >=20 > (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 > .) >=20 Ok. Got your opinion. >=20 > Unfortunately, I'm not even motivated to research this. Based on: >=20 > - 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), >=20 > it's clear that all such research means reverse engineering, and taking > blind shots. >=20 > Once Microsoft are willing to provide clear, detailed, and public > *technical* requirements for firmware (not UEFI plugfest presentations), > we can talk. >=20 > 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. >=20 > 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. > I agree with the restrictions to enable the windows part PXE boot within QE= MU. Fortunately, OVFM has the capability to boot Linux OS via PXE. In curre= nt 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