From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web10.12313.1603796871172101755 for ; Tue, 27 Oct 2020 04:07:51 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=cIhoTTrb; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603796870; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ayKalHTDJJWoBCrSKyl49tzJKSwMvpcECMAO33LDnmc=; b=cIhoTTrbhyHFKuvf5i/YEqCYuUjBa5wG79XRIPFu13H+ihErhs0nr/wPerJojhWzg02g0W zt5+K9TRndeINriYyX+ZTEONEh/Iuxe8lh2tZhDJErK+dGeb1PKvgeokdEUyOL0sjrPBVY KAyI9C4p2eFEwKLmJI/4XsYmBrffPVE= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-355-67DIBWRkN--sKI_0ScCcWw-1; Tue, 27 Oct 2020 07:07:46 -0400 X-MC-Unique: 67DIBWRkN--sKI_0ScCcWw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4779A10E218F; Tue, 27 Oct 2020 11:07:44 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-114-132.ams2.redhat.com [10.36.114.132]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3AA1A75132; Tue, 27 Oct 2020 11:07:42 +0000 (UTC) Subject: =?UTF-8?B?UmU6IOWbnuWkjTog5Zue5aSNOiBbZWRrMi1kZXZlbF0gW1BBVENIIDEvM10gTWRlTW9kdWxlUGtnL0FjcGlUYWJsZUR4ZTogdXNlIHBvb2wgYWxsb2NhdGlvbnMgd2hlbiBwb3NzaWJsZQ==?= To: Ard Biesheuvel , gaoliming , devel@edk2.groups.io Cc: 'Dandan Bi' , 'Jian J Wang' , 'Hao A Wu' , 'Sami Mujawar' , 'Leif Lindholm' References: <20201016154923.21260-1-ard.biesheuvel@arm.com> <20201016154923.21260-2-ard.biesheuvel@arm.com> <009401d6a817$53da54e0$fb8efea0$@byosoft.com.cn> <003401d6ab38$411f31d0$c35d9570$@byosoft.com.cn> <756ec3e7-a1df-8251-f284-07b7aa45ef7f@arm.com> From: "Laszlo Ersek" Message-ID: Date: Tue, 27 Oct 2020 12:07:41 +0100 MIME-Version: 1.0 In-Reply-To: <756ec3e7-a1df-8251-f284-07b7aa45ef7f@arm.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit On 10/26/20 08:42, Ard Biesheuvel wrote: > On 10/26/20 7:25 AM, Laszlo Ersek wrote: >> On 10/26/20 02:35, gaoliming wrote: >>> Ard: >>>    I verify this patch on OvmfX64 and collect the memmap info. I >>> don't see the difference in memmap. >>>    So, this enhancement is for AARCH64 only. Is it right? >> >> That's my understanding, yes. OVMF enables ACPI 1.0b support in the >> bitmask PCD, and so the compat code for 32-bit allocations (= page >> allocations for expressing the 4GB limit) remains active. >> > > Indeed. Any platform that removes BIT1 from > > gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiExposedTableVersions > > will switch over to pool allocations, but OVMF retains support for ACPI > 1.0b for some reason. > I believe OVMF has always had that bit set, and clearing it would risk regressions. The ACPI (AML) generator in QEMU tends restricts itself to ACPI 1.0 constructs (opcodes) because at least the Windows 7 guest OS family cannot deal with ACPI 2.0, as far as I remember. Thanks, Laszlo