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 8CBA321959CB0 for ; Tue, 6 Jun 2017 11:09:34 -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 A41A279702; Tue, 6 Jun 2017 18:10:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A41A279702 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com A41A279702 Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-130.phx2.redhat.com [10.3.116.130]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6D6BE7F8F7; Tue, 6 Jun 2017 18:10:18 +0000 (UTC) To: "Michael S. Tsirkin" Cc: SeaBIOS devel list , qemu devel list , edk2-devel-ml01 , Kevin O'Connor , 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 , Paolo Bonzini References: <2ff62b03-d71b-93c4-79bf-10682b229758@redhat.com> <20170605185815-mutt-send-email-mst@kernel.org> From: Laszlo Ersek Message-ID: Date: Tue, 6 Jun 2017 20:10:17 +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: <20170605185815-mutt-send-email-mst@kernel.org> 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.25]); Tue, 06 Jun 2017 18:10:41 +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: Tue, 06 Jun 2017 18:09:34 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 06/05/17 18:02, Michael S. Tsirkin wrote: > On Sat, Jun 03, 2017 at 09:36:23AM +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. >> >> 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. > > This last option *shouldn't* be complicated. If it is something's wrong. > > Maybe we made a mistake when we added etc/smi/*features*. > > It's not too late to move these to etc/*features* for new > machine types if we want to and if you can do the firmware > work. Then you'd just take out a bit and be done with it. > > I don't insist on doing the ACPI thing now but I do think > infrastructure for negotiating extensions should be there. Different drivers in the firmware would need to negotiate different questions / features with QEMU independently of each other. The "thing" in OVMF that negotiates (and uses) the SMI broadcast is very-very different and separate from the "thing" in OVMF that handles the ACPI linker/loader script. As one example, the first "thing" mentioned above is not even built into ArmVirtQemu (only into OVMF, i.e. x86), while the second "thing" is built into both aarch64 and x86 firmware. So, I think we couldn't share the same fw_cfg files (if they needed write access & lock-down too, i.e. actual negotiation from the firmware) between wildly unrelated features. The virtio feature negotiation is different because each device gets its own negotiation, and that maps very well to UEFI concepts too. BTW, do we have a specific concern relating to the number of fw_cfg files? That count can now be raised from machine type to machine type, but Paolo didn't seem to like raising the current value (or maybe I misunderstood him): http://mid.mail-archive.com/2e6dec37-8b69-979b-c856-406233273066@redhat.com ... Also, above I wrote, with regard to feature negotiation, that it "wouldn't help existing devices". By that I mean this: Consider the NOACPI content hint as an example. If the firmware doesn't negotiate it (before selecting and downloading the ACPI payload), then QEMU cannot generate the NOACPI content hint. In turn QEMU must keep the OVMF SDT Header Probe suppressor (those paddings and AML additions) enabled. But, for the QEMU developers it means that the suppressor code has to be kept around forever, for compatibility with old machine types. And if you do that, then why add a negotiable NOACPI hint at all? That would just further complicate device code (because now you have to generate two different AML payloads), where the old one (the one with the explicit suppressor) would work just fine "forever". Thanks, Laszlo