From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-fo.cableone.cmh.synacor.com (smtp-fo.cableone.cmh.synacor.com [64.8.70.106]) (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 A91601A1E31 for ; Tue, 4 Oct 2016 19:47:07 -0700 (PDT) X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=ZZVfDYdA c=1 sm=1 tr=0 a=F7HL8DhlWvVqsgDc77s/Qg==:117 a=FKkrIqjQGGEA:10 a=m0sRR0la7fUA:10 a=IkcTkHD0fZMA:10 a=20KFwNOVAAAA:8 a=otLtsZP2AAAA:8 a=i3X5FwGiAAAA:8 a=RYJPnzK0AAAA:8 a=scy3HU-E-VRfgP_6us8A:9 a=QEXdDO2ut3YA:10 a=e_O65bzb51kRm2y5VmPK:22 a=gVyqtFkygESWxkzkOzyS:22 a=mmqRlSCDY2ywfjPLJ4af:22 a=71IlbOU7e524H-Equz-4:22 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: c3BhbWNvbGxlY3RvckBjYWJsZW9uZS5uZXQ= Received: from [10.203.0.111] ([10.203.0.111:34859] helo=md11.cableone.synacor.com) by mail.cableone.net (envelope-from ) (ecelerity 3.6.6.45965 r(Core:3.6.6.0)) with ESMTP id 9B/47-07644-AA964F75; Tue, 04 Oct 2016 22:47:07 -0400 Date: Tue, 4 Oct 2016 22:47:06 -0400 (EDT) From: spam collector To: Laszlo Ersek Cc: edk2-devel@ml01.01.org Message-ID: <1410853764.96270806.1475635626572.JavaMail.zimbra@cableone.net> In-Reply-To: <94a76bd7-732c-c8f6-b8be-8175dd061b86@redhat.com> 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> MIME-Version: 1.0 X-Originating-IP: [174.126.140.68] X-Mailer: Zimbra 8.0.7_GA_6021 (ZimbraWebClient - FF49 (Win)/8.0.7_GA_6021) Thread-Topic: OVMF.fd and placement of EfiBootServicesData Thread-Index: fjCuw98I3qpedAIukofLHJZ/xt+tkQ== 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: Wed, 05 Oct 2016 02:47:07 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- 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 > > On 10/04/16 18:39, spam collector wrote: > > > [...] I was surprised to see that QEMU and/or > > OVMF requires the NvVars file to exist on the partition, else OVMF > > does not even show the shell, even on a perfectly valid partitioned > > image. I don't know if this is QEMU's fault or OVMF's fault. If > > the NvVars file does not exist, is it the desired option to fail > > the loading of the shell? If the file does not exist, can OVMF use > > default values and still load the shell? > > OVMF does not require the NvVars file to exist. The NvVars file is only > used / relied on when the QEMU command line is incorrect, that is, when > it does not configure the pflash chip(s) for storing the firmware binary > and/or the variable store. > > * The command line that you are likely used to goes like this: > > qemu-system-x86_64 -bios OVMF.fd ... Yes. I am currently using that line with the only modification of the 32-bit emulation on both parts. > This is broken. Don't use it. The OVMF.fd file in the above usage is a > unified file (1MB or 2MB in size), containing both the firmware binary > and an empty (pre-formatted) variable store. The entire file is mapped > into guest memory as ROM. The variable store area is not writeable, > hence OVMF falls back to the NvVars based emulation. That emulation is > not entirely compatible with the UEFI spec. Don't use the above command > line. > > * 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. > The OVMF.fd file has the same characteristics as above, but the same > stuff is mapped as a programmable pflash chip into guest memory. It > means that the guest memory area in question *normally* reads and > executes like normal RAM, but if you write to it (that is, if OVMF's > flash driver writes to it), it is flipped into "programming mode", where > you can read and write the device using various "commands". One of those > commands flips the device back to "normal" mode. > > In this mode, the NvVars-based emulation is not used, and the variable > store / variable services will work as defined by the UEFI spec. > > The problem with this approach is that the OVMF.fd file contains both a > firmware binary and a live variable store. You cannot upgrade the > firmware binary without losing the VM's long-term, non-volatile variables. > > * The second stage improvement is the following command line: > > # create the virtual machine's private variable store from the > # pristine variable store template, if the former doesn't exist yet, > # or has been lost for some reason > if ! [ -e GUEST_1_VARS.fd ]; then > cp OVMF_VARS.fd GUEST_1_VARS.fd > fi > > qemu-system-x86_64 \ > -drive if=pflash,format=raw,unit=0,readonly,file=OVMF_CODE.fd \ > -drive if=pflash,format=raw,unit=1,file=GUEST_1_VARS.fd \ > ... > > In this case, the OVMF_CODE.fd and OVMF_VARS.fd are used separately. > (You can find both files under the Build directory; plus Gerd Hoffmann's > RPM files also package them.) For the life of me I could not find any directory called "Build". I did find a few RPM files and one of them contained: OVMF_CODE-pure-efi.fd and OVMF_VARS-pure-efi.fd However, no matter the emulation (32- or 64-bit), neither worked and would get as far as printing the '.' just before the .FLOPPY failed .CD-ROM failed etc. lines and go no further. Thank you for the excellent description, however sorry for my ignorance. If you don't mind, would you please specify a specific URL that contains the two files you speak of, whether it be a listing of those files, a .gz file, or even a .rpm file. Thank you, Ben