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 168B221A09105 for ; Mon, 5 Jun 2017 02:53:37 -0700 (PDT) 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 mx1.redhat.com (Postfix) with ESMTPS id E18B6C83D; Mon, 5 Jun 2017 09:54:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E18B6C83D 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=imammedo@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com E18B6C83D Received: from nial.brq.redhat.com (dhcp-1-118.brq.redhat.com [10.34.1.118]) by smtp.corp.redhat.com (Postfix) with ESMTP id 53FA681991; Mon, 5 Jun 2017 09:54:35 +0000 (UTC) Date: Mon, 5 Jun 2017 11:54:29 +0200 From: Igor Mammedov To: Laszlo Ersek Cc: SeaBIOS devel list , qemu devel list , edk2-devel-ml01 , Stefan Berger , Ben Warren , Ard Biesheuvel , Xiao Guangrong , "Jordan Justen \(Intel address\)" , "Michael S. Tsirkin" , "Dr. David Alan Gilbert" , "Leif Lindholm \(Linaro address\)" , Dongjiu Geng , Kevin O'Connor , Gerd Hoffmann , Shannon Zhao Message-ID: <20170605115429.29c252f6@nial.brq.redhat.com> In-Reply-To: <2ff62b03-d71b-93c4-79bf-10682b229758@redhat.com> References: <2ff62b03-d71b-93c4-79bf-10682b229758@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Mon, 05 Jun 2017 09:54:42 +0000 (UTC) Subject: Re: [Qemu-devel] 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: Mon, 05 Jun 2017 09:53:37 -0000 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sat, 3 Jun 2017 09:36:23 +0200 Laszlo Ersek wrote: > On 06/02/17 17:45, Laszlo Ersek wrote: > > > 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. > > Dave made a good point (which I should have realized myself, really!), > namely if you launch old fw on old qemu, then migrate the guest to a new > qemu and then reboot the guest on the target host, within the migrated > VM, things will break. [...] > Regarding the NOACPI hint, I guess I'm dropping that. I only meant > NOACPI for addressing Igor's long-standing dislike for the "ACPI SDT > header probe suppression" in VMGENID (and future similar devices). But, > there's no actual *technical* need to eliminate that I'd consider eliminating wasting space technical need, but there are not a lot of tables that need it so far and implementing NOACPI hint would lead to all out compat logic impl. along with it (either negotiation or machine versioning). The later seem to me too much so I wouldn't bother with it yet. > (unlike the technical need for 64-bit blob allocations which should really be > solved) here I disagree, having 32bit pointer is sufficient enough hint. Yep, firmware have to scan linker script to determine limits before doing allocations but it's totally upto firmware to decide where to allocate tables. It also helps to avoid in qemu 2 points where we'd have to specify that table is "64 bit-able" in add_pointer and allocate. BTW: how OVMF would deal with booting 32-bit OS if it would allocate ACPI tables above 4Gb? For BIOS on baremetal I'd expect some switch in settings, something like "Disable 32-bit OS support". > Self-nack for this set of sets. > > Thanks for the feedback, > Laszlo >