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 5F5AB1A1E4D for ; Mon, 3 Oct 2016 02:42:10 -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 CDA02461EA; Mon, 3 Oct 2016 09:42:09 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-9.phx2.redhat.com [10.3.116.9]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u939g8nO027256; Mon, 3 Oct 2016 05:42:09 -0400 To: spam collector References: <1825038664.87486514.1475464584880.JavaMail.zimbra@cableone.net> From: Laszlo Ersek Cc: edk2-devel@ml01.01.org Message-ID: <9f2b0b8c-9bfb-dd73-f7cb-cd6df775c237@redhat.com> Date: Mon, 3 Oct 2016 11:42:08 +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: <1825038664.87486514.1475464584880.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.29]); Mon, 03 Oct 2016 09:42:09 +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: Mon, 03 Oct 2016 09:42:10 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 10/03/16 05:16, spam collector wrote: > Hello, > Forgive me for not searching for this first, but gmane.org has > been down for a little while. Therefore, forgive me if this > question has been asked and answered. > I am using OVMF.fd and QEMU for Windows and tried to load > a large file to physical address 0x00800000. When an error > was returned, I found that OVMF has reserved an amount of > EfiBootServicesData within/around that location. > Here is a memory dump using the BootServices MemoryMap Service: > Start: 0x00000000->0x0009FFFF, Pgs: 160, EfiConventionalMem > Start: 0x00100000->0x003FFFFF, Pgs: 768, EfiConventionalMem > Start: 0x00400000->0x0040BFFF, Pgs: 12, EfiBootServicesCode > Start: 0x0040C000->0x0081FFFF, Pgs: 1044, EfiConventionalMem > Start: 0x00820000->0x00FFFFFF, Pgs: 2016, EfiBootServicesData > Start: 0x01000000->0x0BFFFFFF, Pgs: 1044, EfiConventionalMem > ... and so on > Without the idea of "you should make your code relocatable, > i.e.: not care where it is in memory", or if I say that I *must* have > the memory from 0x00800000 to 0x00FFFFFFavailable, > without re-building OVMF.fd, is there a way to tell the system > to use a different address for that portion of EfiBootServiceCode? > I tried manipulating NvVars with a few entries to no avail. > I added the "LoadFixedAddressConfigurationTable" entry hoping > that I could set a minimum location, too without success. > So, without rebuilding OVMF.fd, which would require everyone > whom wished to use my code to do so, or at least download it > from me, and I don't like modified packages of other's work > floating around, is there a why to tell OVMF.fd/the EFI system > to not use memory below a certain address? > Thank you in advance for your suggestions, Sorry, I don't think I can help. You can read about the OVMF memory map in the (now somewhat outdated) OVMF whitepaper at http://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt section A comprehensive memory map of OVMF You'd like to place your stuff at 8192 KB .. 16384 KB, but as you can see from the map, that exact range is heavily used by OVMF itself. (As I said, some of those exact values are no longer current, due to the following commits since: 08df58ec3043 OvmfPkg: raise DXEFV size to 9 MB 2f7b34b20842 OvmfPkg: raise DXEFV size to 10 MB 45d870815156 OvmfPkg/PlatformPei: rebase and resize the permanent PEI memory for S3 6b04cca4d697 OvmfPkg: remove PcdS3AcpiReservedMemoryBase, PcdS3AcpiReservedMemorySize but the main layout remains the same.) Please consider making your code relocatable. Thanks Laszlo