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 6A32321A08D8A for ; Tue, 6 Jun 2017 10:51:24 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BD5E64DD4B; Tue, 6 Jun 2017 17:52:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com BD5E64DD4B Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com BD5E64DD4B Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-130.phx2.redhat.com [10.3.116.130]) by smtp.corp.redhat.com (Postfix) with ESMTP id 863F35C6DB; Tue, 6 Jun 2017 17:52:22 +0000 (UTC) To: Igor Mammedov Cc: SeaBIOS devel list , qemu devel list , edk2-devel-ml01 , Stefan Berger , Ben Warren , Ard Biesheuvel , Xiao Guangrong , "Jordan Justen (Intel address)" , "Michael S. Tsirkin" , "Dr. David Alan Gilbert" , "Leif Lindholm (Linaro address)" , Dongjiu Geng , Kevin O'Connor , Gerd Hoffmann , Shannon Zhao References: <2ff62b03-d71b-93c4-79bf-10682b229758@redhat.com> <20170605115429.29c252f6@nial.brq.redhat.com> From: Laszlo Ersek Message-ID: <7a08004a-cc4d-6144-4fc8-4b85062033e8@redhat.com> Date: Tue, 6 Jun 2017 19:52:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170605115429.29c252f6@nial.brq.redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 06 Jun 2017 17:52:31 +0000 (UTC) Subject: Re: [Qemu-devel] allocation zone extensions for the firmware linker/loader 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, 06 Jun 2017 17:51:24 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 06/05/17 11:54, Igor Mammedov wrote: > BTW: > how OVMF would deal with booting 32-bit OS if it would allocate > ACPI tables above 4Gb? > For BIOS on baremetal I'd expect some switch in settings, something > like "Disable 32-bit OS support". In order to answer your question exhaustively, I'd have to ponder this a lot longer. For now my basic answer is the following: - If you can allocate memory above 4GB in the DXE phase, that means your DXE and BDS phases are 64-bit. Which in turn implies you *cannot* boot a 32-bit OS at all. Generally speaking, with PI / UEFI, the bitness of the firmware (the DXE and the BDS phases) and the bitness of the OS (incl. its UEFI boot loader) must be identical. As a trick, Linux can work around this, in *one* direction -- 64-bit Linux can run on 32-bit UEFI firmware (on x86; not sure about other arches). But, the other direction (32-bit UEFI OS on 64-bit firmware) cannot work, minimally because you can only call the UEFI runtime services in 64-bit mode. In short (again, this is quite rudimentary), if your memory allocation in the DXE and/or BDS phases ends up being served from above 4GB, you won't be booting a 32-bit-only OS. Thanks Laszlo