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 084BB82237 for ; Tue, 21 Feb 2017 19:31:24 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 79D75C057FA9; Wed, 22 Feb 2017 03:31:24 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-134.phx2.redhat.com [10.3.116.134]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v1M3VMbF000859; Tue, 21 Feb 2017 22:31:22 -0500 To: Jordan Justen , "Kinney, Michael D" , "Yao, Jiewen" , edk2-devel-01 References: <74D8A39837DF1E4DA445A8C0B3885C503A8F2DE0@shsmsx102.ccr.corp.intel.com> <148772709277.12591.2606094062546040536@jljusten-ivb> <234e56b7-7eb4-3220-8335-2887a084b30f@redhat.com> <148773204321.13093.9257287652423723407@jljusten-ivb> Cc: "Ni, Ruiyu" , Andrew Fish , Ard Biesheuvel From: Laszlo Ersek Message-ID: Date: Wed, 22 Feb 2017 04:31:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 22 Feb 2017 03:31:24 +0000 (UTC) Subject: Re: memory type information HOB / UEFI memmap defrag X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 03:31:24 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 02/22/17 04:14, Laszlo Ersek wrote: > Mike, > > On 02/22/17 03:54, Jordan Justen wrote: >> On 2017-02-21 18:46:01, Kinney, Michael D wrote: >>> Laszlo, >>> >>> The only side effect of not producing the HOB when the variable does >>> not exist is that the first boot of a platform has a fragmented >>> memory map > > We have a permanently fragmented map now :) (Although, I guess it could > be even worse; the HOB that we produce now likely does help a bit.) > >>> and you may get an extra reboot when the variable is set. > > I think I could live with that. > > In fact, if the reboot is *guaranteed* if the variable does not exist, > that's likely best, because this way a fragmented memmap is never > exposed to a guest OS. > >>> A fragmented memory map will also be produced if the variable store >>> contents are corrupt or zeroed. > > If that was hidden from the OS by a guaranteed reboot, I think I'd > welcome that reboot. It's a very infrequent occurrence. > > Jordan, > >> Would it be possible to inhibit the reboot until we fully support S4? > > I'm not very worried about the reboot; using pflash and longer-term > guests, it should happen very rarely. > > For one-off guests though... Hm, I guess it might be somewhat annoying, > so if we can find a solution for avoiding the reboot even when the > variable is missing, that would be more elegant. > >> I think it'd be fine to have a fragmented map for one boot if it was >> corrected on future boots of the machine. > > Is this a trade-off we can control somehow? > > I think you're starting to convince me that it's more user friendly to > expose a fragmented map *once* than to auto-reboot *once*. > >> I think we should consider continuing to produce the HOB in >> PlatformPei if we can fairly easily reduce the fragmentation on the >> first boot via the HOB. > > Sure, we can bump the values in the HOB; however, the problem is with > identifying "first boot" (= presence of the variable) in PlatformPei, to > see if we should produce the default HOB. That opens the same can of > worms :( > > I mean we can install a PPI notify callback for the r/o variable PPI in > PlatformPei, and then install the HOB in the callback if the variable is > missing. It's just too much work. > > Hm, wait, we already call PeiServicesNotifyPpi() in PlatformPei, for the > MP Services PPI (which we use to program the Feature Control MSR on all > VCPUs if instructed so by QEMU). Then I guess I'm out of arguments; we > should at least try this. Sigh. :) > > Do you want to reopen > ? I just closed it > because there didn't seem to be an actual use case for VariablePei, but > now we may have found one, independently of the original reporter's > (non-upstream) use case. There's at least one big complication though. OVMF still supports a RAM-emulated varstore, in addition to pflash. The pflash location is known in advance (it is a set of constants from the build process), but the area for the emulation is allocated dynamically during PEI. And, we only really decide which one to use for variables in the DXE phase (that's when we check for the presence of pflash). This sort of throws a wrench into VariablePei's gears; we cannot tell it where to look for the varstore. We could move the flash detection from DXE to PEI, but that's again too much complication for this -- if we could mitigate the fragmentation by bumping the constants in our current HOB, that would look way more attractive to me. If we removed the RAM-emulated varstore fully, and required pflash no matter what, then I might feel differently, I think. Thanks Laszlo