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 C49561A1DEB for ; Thu, 6 Oct 2016 00:39:41 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 54CE93D943; Thu, 6 Oct 2016 07:39:41 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-80.phx2.redhat.com [10.3.116.80]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u967ddFN024893; Thu, 6 Oct 2016 03:39:40 -0400 To: spam collector References: <1825038664.87486514.1475464584880.JavaMail.zimbra@cableone.net> <9f2b0b8c-9bfb-dd73-f7cb-cd6df775c237@redhat.com> <812341546.91963700.1475549145141.JavaMail.zimbra@cableone.net> <5c54ce38-9f0c-ac8d-c926-570ebc3dd720@redhat.com> <1747186652.93714260.1475599157436.JavaMail.zimbra@cableone.net> <94a76bd7-732c-c8f6-b8be-8175dd061b86@redhat.com> <1410853764.96270806.1475635626572.JavaMail.zimbra@cableone.net> <280e3403-1821-396e-5243-54b770dcb01a@redhat.com> <1208026991.99496554.1475723134167.JavaMail.zimbra@cableone.net> Cc: edk2-devel@ml01.01.org From: Laszlo Ersek Message-ID: <3d3c1cb5-ca15-c030-4216-f115116c8da4@redhat.com> Date: Thu, 6 Oct 2016 09:39:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <1208026991.99496554.1475723134167.JavaMail.zimbra@cableone.net> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 06 Oct 2016 07:39:41 +0000 (UTC) Subject: Re: OVMF.fd and placement of EfiBootServicesData X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 07:39:42 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 10/06/16 05:05, spam collector wrote: > ----- Original Message ----- >> From: "Laszlo Ersek" >> To: "spam collector" >> Cc: edk2-devel@ml01.01.org >> Sent: Wednesday, October 5, 2016 8:28:46 AM >> Subject: Re: [edk2] OVMF.fd and placement of EfiBootServicesData >> >> On 10/05/16 04:47, spam collector wrote: >>> >>> ----- Original Message ----- >>>> From: "Laszlo Ersek" >>>> To: "spam collector" >>>> Cc: edk2-devel@ml01.01.org >>>> Sent: Tuesday, October 4, 2016 10:22:34 AM >>>> Subject: Re: [edk2] OVMF.fd and placement of EfiBootServicesData >> >>>> * The first stage improvement is the following command line: >>>> >>>> qemu-system-x86_64 -pflash OVMF.fd >>> >>> This did not work either with or without the NvVars file present. >> >> I think I'll need a more complete issue riport then -- what is your >> exact QEMU command line, and what OVMF binary are you using? > > "..\qemu-system-i386w.exe" -m 256 -localtime > -drive file=uefi.bin.vhd,format=raw,if=ide,media=disk,index=0 > -pflash ..\OVMF.fd -parallel file:para.txt > > Remember that I am running this in WinXPSP3. First, I can't "remember" it, because this is the first time you state that. :) Second, WinXPSP3 as host machine, really?... :) Anyway, if both your QEMU and OVMF builds are okay / fresh enough, using OVMF with TCG (i.e., not KVM) should work, yes. > Also, the version of > OVMF.fd is from http://www.tianocore.org/ovmf/ and I just noticed > that that page has been recently changed. That's a coincidence, but not a random one. Users have been repeatedly confused by the r15214 binary, which at this point was more than 2.5 years old. Just before your query, I noticed (and marked it invalid); the reporter of that issue was also tripped up by the ancient r15214 build. So I asked Jordan to please update the page you reference, with a link to Gerd's RPMs, which are bleeding edge builds. > You use to be able to > download the OVMF.fd directly from that page. It was r15214, which > I found out yesterday, is an older version. > >>> I did find a few RPM files and one of them contained: >>> OVMF_CODE-pure-efi.fd >>> and >>> OVMF_VARS-pure-efi.fd >> >> Yes, they are from Gerd's "edk2.git-ovmf-ia32" package (since you >> mention IA32), from , and they are >> recommended to use. > > I also could not get these to work. I will do a little more > research into why not and be sure to let you know. > >> Otherwise, download the "edk2.git-ovmf-ia32" or "edk2.git-ovmf-x64" RPM >> file (as needed) from , and >> extract it with: >> >> rpm2cpio FILENAME | pax -r -v >> >> The extracted files you want are: >> >> usr/share/edk2.git/ovmf-*/OVMF_CODE-pure-efi.fd >> usr/share/edk2.git/ovmf-*/OVMF_VARS-pure-efi.fd >> usr/share/edk2.git/ovmf-*/UefiShell.iso > > These are the three files I used and could not get the shell to load. > I will try a few other things and get back with you. > > Please note that I am using the Windows port of QEMU from > https://qemu.weilnetz.de/ on a WinXP host, if that makes any > difference. It could make a difference. I've never ever used Windows binaries of QEMU. OTOH several people on this list have used such with success, so I can't say definitely either way. > > Also, one more question. I can make my GPT image either have a legacy > MBR with two entries pointing to one partition each or I can have a > Protected MBR that encompasses the whole GPT, both partitions, and the > backup items. > > With the r15214 version and: > > "..\qemu-system-i386w.exe" -m 256 -localtime > -drive file=uefi.bin.vhd,format=raw,if=ide,media=disk,index=0 > -bios ..\OVMF.fd -parallel file:para.txt > > it would boot to the shell either way and load and run my BOOT.efi file > just fine, whether I had a Legacy MBR or a PMBR. Does this make a > difference with the new image(s) you mention above. Sorry, I don't have any particular expertise with GPT. I believe the PartitionDxe driver that's built into OVMF received some updates over that 2.5y interval that I mentioned above. > Also, please note that the hard drive image is a VHD image, a > raw image with a single sector at the end for the VHD info so that > Oracles VM Box will boot it. This means that the backup GPT header > is *not* the last sector of the disk. As far as I know, QEMU supports VHDX. However, you pass a VHD image to -drive with format=raw. That looks very broken. I guess I'd suggest matching the actual image format with the format=... property. If you pass format=raw, the VHD metadata at the end of the image will be visible to the guest (as garbage). > The > > -bios OVMF.fd > > version boots it just fine in QEMU, but I thought I would mention > this in case the new code expects it to be in the last sector. I'm quite certain all GPT drivers in the guest expect a valid disk image, and format=raw, on a VHD disk image, seems to break that. Laszlo