Re: memory type information HOB / UEFI memmap defrag

[Laszlo Ersek <lersek@redhat.com>]

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
> <https://bugzilla.tianocore.org/show_bug.cgi?id=386>? 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