From: "Wu, Jiaxin" <jiaxin.wu@intel.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: edk2-devel-01 <edk2-devel@lists.01.org>
Subject: Re: OVMF OS boot
Date: Tue, 11 Jul 2017 03:18:26 +0000 [thread overview]
Message-ID: <895558F6EA4E3B41AC93A00D163B7274162E6EA3@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <c50a1cfd-8abc-5cc7-0d62-d3c90b403389@redhat.com>
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
prev parent reply other threads:[~2017-07-11 3:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-07 3:40 OVMF OS boot Wu, Jiaxin
2017-07-07 11:40 ` Laszlo Ersek
2017-07-11 3:18 ` Wu, Jiaxin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=895558F6EA4E3B41AC93A00D163B7274162E6EA3@SHSMSX103.ccr.corp.intel.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox