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 622BE21AE30C3 for ; Sat, 3 Jun 2017 00:35:30 -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 F31F9C049D59; Sat, 3 Jun 2017 07:36:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com F31F9C049D59 Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com F31F9C049D59 Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-19.phx2.redhat.com [10.3.116.19]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2C4677A4DC; Sat, 3 Jun 2017 07:36:24 +0000 (UTC) From: Laszlo Ersek To: SeaBIOS devel list , qemu devel list , edk2-devel-ml01 Cc: Kevin O'Connor , "Michael S. Tsirkin" , Ard Biesheuvel , Ben Warren , Dongjiu Geng , Igor Mammedov , "Jordan Justen (Intel address)" , "Leif Lindholm (Linaro address)" , Shannon Zhao , Stefan Berger , Xiao Guangrong , "Dr. David Alan Gilbert" , Gerd Hoffmann References: Message-ID: <2ff62b03-d71b-93c4-79bf-10682b229758@redhat.com> Date: Sat, 3 Jun 2017 09:36:23 +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.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Sat, 03 Jun 2017 07:36:33 +0000 (UTC) Subject: Re: 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: Sat, 03 Jun 2017 07:35:30 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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. So that makes this approach dead in the water. Possible mitigations I could think of: - Make it machine type dependent. Complicated (we don't usually bind ACPI generation to machine types) and wouldn't help existing devices. - Let the firmware negotiate these extensions. Very complicated (new fw-cfg files are needed for negotiation) and wouldn't help existing devices. So I guess I'll do what Igor and Gerd suggested: record in advance whether any pointer field narrower than 8 bytes points into a given blob, and if so, forbid allocating that blob from 64-bit address space. This should solve Ard's needs purely within the firmware. 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 (unlike the technical need for 64-bit blob allocations which should really be solved), so I guess it's OK to postpone NOACPI indefinitely. Self-nack for this set of sets. Thanks for the feedback, Laszlo