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 18EE421A08D89 for ; Thu, 1 Jun 2017 13:39:19 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2670A3DBED; Thu, 1 Jun 2017 20:40:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2670A3DBED Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 2670A3DBED 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 115C8183A5; Thu, 1 Jun 2017 20:40:08 +0000 (UTC) From: Laszlo Ersek To: Ard Biesheuvel , edk2-devel@lists.01.org Cc: leif.lindholm@linaro.org, jordan.l.justen@intel.com, Shannon Zhao , "Michael S. Tsirkin" , Igor Mammedov , qemu devel list , gengdongjiu , Drew Jones , Gerd Hoffmann References: <20170601112241.2580-1-ard.biesheuvel@linaro.org> Message-ID: Date: Thu, 1 Jun 2017 22:40:07 +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: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 01 Jun 2017 20:40:20 +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 20:39:19 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 06/01/17 14:25, Laszlo Ersek wrote: > In QEMU, we could tie both of these extensions to new machine types. > > The result would be: > > firmware QEMU QEMU machine type result > -------- ---- ----------------- ----------------------------------- > old new old allocate blobs under 4GB > old new new breakage, but that's OK, we can > require refreshed firmware for > new machine types > new old old allocate blobs under 4GB > new new old allocate blobs under 4GB > new new new allocate blobs from 64-bit space I think the situation is easier than this. We don't have to tie the extensions to machine types. The reason is that old firmware is allowed to fail on new QEMU (regardless of machine type). Example: the WRITE_POINTER command, originally introduced for VMGENID. If you run a SeaBIOS binary without WRITE_POINTER support, in a QEMU VM with "-device vmgenid", the device will not work. And QEMU doesn't try to prevent that by binding vmgenid to machine types. Instead, QEMU bundled a SeaBIOS binary with WRITE_POINTER support, for the release that introduced VMGENID. (There's no reason for not bundling OVMF and ArmVirtQemu binaries with QEMU releases now. Gerd already has a build service up and running, at .) The scenario that we *should* avoid is new firmware failing on old QEMU. And this patch is actually that case, because the new fw would allocate blobs with such 8-byte addresses that might not fit into 32-bit blob fields. So, the extensions are necessary, but tying them to machine types isn't. firmware QEMU result -------- ---- ------------------------------------------------------ old new breakage, but that's OK; we can require refreshed firmware for new QEMU releases new old allocate blobs under 4GB (alloc zone extension is necessary) new new allocate blobs from any address range Thanks Laszlo