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 D5F4B21A08D63 for ; Thu, 1 Jun 2017 09:36:49 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D5459804EB; Thu, 1 Jun 2017 16:37:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D5459804EB Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com D5459804EB Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-77.phx2.redhat.com [10.3.116.77]) by smtp.corp.redhat.com (Postfix) with ESMTP id 870AC53CD0; Thu, 1 Jun 2017 16:37:48 +0000 (UTC) To: Igor Mammedov Cc: Ard Biesheuvel , edk2-devel@lists.01.org, leif.lindholm@linaro.org, jordan.l.justen@intel.com, Shannon Zhao , "Michael S. Tsirkin" , qemu devel list , gengdongjiu , Drew Jones References: <20170601112241.2580-1-ard.biesheuvel@linaro.org> <20170601171650.4a196f36@nial.brq.redhat.com> From: Laszlo Ersek Message-ID: <3de97c67-5b9d-35a0-ec5d-0098180dec9b@redhat.com> Date: Thu, 1 Jun 2017 18:37:47 +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: <20170601171650.4a196f36@nial.brq.redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 01 Jun 2017 16:37:51 +0000 (UTC) Subject: Re: [RFC PATCH] OvmfPkg/AcpiPlatformDxe: lift 4 GB alloc limit for modern ACPI systems 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: Thu, 01 Jun 2017 16:36:50 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 06/01/17 17:16, Igor Mammedov wrote: > On Thu, 1 Jun 2017 14:25:48 +0200 > Laszlo Ersek wrote: > >> On 06/01/17 13:22, Ard Biesheuvel wrote: >>> ACPI supports architectures such as arm64, which did not exist when the >>> original 32-bit ACPI 1.0 was introduced. These days, ACPI tables can all >>> support 64-bit memory addresses, and so QEMU has been updated to emit >>> 64-bit table and entry point types on arm64/mach-virt. >> >> Do you have commit cb51ac2ffe36 ("hw/arm/virt: generate 64-bit >> addressable ACPI objects", 2017-04-10) in mind? > My understanding was that OVMF discards RSDP/[RX]SDT so that commit > probably irrelevant. OVMF does not install these root tables, that's correct, but it does execute the commands that refer to the blob(s) that contain these tables. So for example pointers and checksums are updated, it's only the last heuristics phase that detects if a pointer points to RSDT / XSDT and then those tables are not installed. OVMF catches pointer field overflows, and rolls back the entire processing if one occurs. So the commit in question is certainly relevant; without it, a >4GB allocation address would be added to an RSDT entry (which is 4-byte wide), and that would fail the entire process. > Now about FADT or any other blob, do we really need to extend > loader protocol? Couldn't firmware decide where to allocate > table based on size in add_pointer commands? > > That might be a bit complicated but on the bright side is that > it is firmware only change and it should work both on old and > new qemu without breaking anything. For this I'd have to pre-scan the ADD_POINTER commands, and for target blob ever pointed-at by them, find the minimum referring pointer width. If that minimum width is smaller than 8 bytes, the pointed-at blob must be allocated under 4GB. I think this is too complex (it would add a third pass to OVMF's processing), especially given that we already have a dedicated Zone field that specifically tells the firmware where the blobs should be allocated. The goal is to decrease the dirty tricks in OVMF, not increase them. Furthermore, this wouldn't help us turn off the SDT header probing in OVMF (the feature that currently requires those strange AML-level offset increments, into blobs that don't host ACPI tables). Suppressing the probe in a nice way surely needs a specific hint, so we might as well handle both cases with Zone extensions. Laszlo