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 C5FE821C8D60F for ; Fri, 2 Jun 2017 08:44:26 -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 930B77E9CA; Fri, 2 Jun 2017 15:45:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 930B77E9CA Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 930B77E9CA Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-83.phx2.redhat.com [10.3.116.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id F342E7F469; Fri, 2 Jun 2017 15:45:22 +0000 (UTC) To: SeaBIOS devel list , qemu devel list , edk2-devel-ml01 Cc: Kevin O'Connor , "Michael S. Tsirkin" , Ard Biesheuvel , Ben Warren , Dongjiu Geng , Igor Mammedov , "Jordan Justen (Intel address)" , "Leif Lindholm (Linaro address)" , Shannon Zhao , Stefan Berger , Xiao Guangrong From: Laszlo Ersek Message-ID: Date: Fri, 2 Jun 2017 17:45:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 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.26]); Fri, 02 Jun 2017 15:45:29 +0000 (UTC) Subject: 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: Fri, 02 Jun 2017 15:44:27 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Hi, this message is cross-posted to three lists (qemu, seabios, edk2). I'll follow up with three patch series, one series for each project. I'll cross-post all of the patches as well, but I'll add the project name in the "bag of tags" in the subject lines. The QEMU series introduces two extensions to the ALLOCATE firmware linker/loader command. One extension is a new allocation zone, with value 3, for allowing the firmware to allocate the fw_cfg blobs in 64-bit address space. The other extension is a repurposing of the most significant bit (bit 7) in the zone field. This bit becomes orthogonal to the rest of the zone field. If the bit is set, it means that QEMU promises the firmware that the blob referenced by the ALLOCATE command contains no ACPI tables at all. After introducing these, the QEMU series puts them to use, covering all of the currently generated ALLOCATE commands, as appropriate. Among the benefits we can mention - the removal of the OVMF ACPI SDT Header Probe suppressor from VMGENID (and from any similar future devices), - and the fact that the "virt" machine type (and maybe other machine types) of the arm/aarch64 target will no longer require RAM under 4GB for ACPI to work. Both of these extensions are irrelevant for SeaBIOS, therefore the SeaBIOS patches simply mask out bit 7 (for ignoring the "no ACPI content" hint), and fall back to the HIGH zone (= 32-bit address space) when the 64-bit zone is permitted. In other words, SeaBIOS needs some patches to recognize the new zone values, but beyond that, the behavior is unchanged. Both extensions are important for virtual UEFI firmware (OVMF in x86 guests and ArmVirtQemu in aarch64 guests). The edk2 patches add support to OvmfPkg/AcpiPlatformDxe for the extensions. Please see the commit messages for details (all the extensions are explained in detail in the relevant patches for all of the projects). The patches can cause linker/loader breakage when old firmware is booted on new QEMU. However, that's no problem (it's nothing new), the next release of QEMU should bundle the new firmware binaries as always. New firmware will continue running on old QEMU without issues. (In case you have sent me emails about this in the last few tens of hours, please know that I'm not ignoring them, I just haven't seen / read them. Reading emails every five minutes makes focused work impossible, so when I'm busy, I tend to read email once per day.) Thanks Laszlo