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 7C22221C8D62B for ; Fri, 2 Jun 2017 15:39:25 -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 C6FF880F63; Fri, 2 Jun 2017 22:40:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C6FF880F63 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 C6FF880F63 Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-35.phx2.redhat.com [10.3.116.35]) by smtp.corp.redhat.com (Postfix) with ESMTP id 62B6E781E0; Fri, 2 Jun 2017 22:40:21 +0000 (UTC) To: Gerd Hoffmann , 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 References: <20170601112241.2580-1-ard.biesheuvel@linaro.org> <1496415382.16895.4.camel@redhat.com> From: Laszlo Ersek Message-ID: Date: Sat, 3 Jun 2017 00:40:20 +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: <1496415382.16895.4.camel@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]); Fri, 02 Jun 2017 22:40:28 +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: Fri, 02 Jun 2017 22:39:25 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 06/02/17 16:56, Gerd Hoffmann wrote: > Hi, > >> 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. > > Old seabios will work just fine on new qemu as long as you don't use > the vmgenid device. > > Only when using new features (which require firmware support) new > seabios is needed, and usually we update seabios for that reason. We > want the new features be usable of course. But in general there are no > lockstep updates for qemu and seabios (any more). > >> 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. > > I think ovmf simply checking whenever the pointer fields are 32bit or > 64bit, then doing allocations accordingly (as Igor suggested) would be > the best. Why ask qemu for a hint when ovmf can figure on its own? > That adds a new interface and new config knobs for IMO no good reason. There is a good reason: the reason is that OVMF should not be forced to reverse-engineer such information with a third, separate pass over the linker/loader script, adding yet more complexity. The linker/loader interface was designed for SeaBIOS, without any regard to OVMF / ArmVirtQemu. For example, SeaBIOS gets hints like HIGH vs. FSEG (which distinction is irrelevant for OVMF / ArmVirtQemu) despite the fact that SeaBIOS could also figure that out one way or another if it really wanted to. OVMF / ArmVirtQemu need different kinds of hints, and I think they should get them at this point. Even now, OVMF deduces the starts of individual ACPI tables in the blobs by using somewhat messy heuristics. (OVMF *must* know where the tables start.) The heuristics incur no false negatives, but a chance exists for false positives, unless QEMU takes extra precautions. But Igor happens to hate those precautions, and the TCPA and NVDIMM authors have completely missed them. So we should have fewer of these heuristics and workarounds, not more. And, as I replied to Igor earlier, the other blob allocation hint (the "no ACPI content" hint that allows QEMU to drop precisely the above obscure precautions, i.e. the "ACPI SDT header probe suppressor"), necessitates extending the ALLOCATE command anyway. Would it help if I made these extensions dependent on 2.10+ machine types? (Obviously existing generators like TCPA, NVDIMM and VMGENID would not be modified then, because the old stuff would have to be preserved for old machine types anyway.) Thanks Laszlo