kern: physmem: improve region coalescing logic

[kevans]

Summary

The existing logic didn't take into account newly inserted mappings
wholly contained by an existing region (or vice versa), nor did it
account for weird overlap scenarios. The latter is probably unlikely
to happen, but the former may happen in UEFI: BootServicesData allocated
within a large chunk of ConventionalMemory. This situation blows up vm
initialization.

While we're here, remove the "exact match" logic as it's likely wrong;
if an exact match exists with conflicting flags, for instance, then we
should probably be doing something else. The new logic takes into
account exact matches as part of the overlapping efforts.

[kib]

It would be great if at least x86 was changed to use this KPI.

sys/kern/subr_physmem.c

363–364

I think, at this point you need to check both siblings and see if any of them coalesce as well.
Then you would need to compact the regions array.

370

Same

[kevans]

sys/kern/subr_physmem.c

363–364

I had to stare at it for a bit, but I think I mostly agree on both cases -- if the lower sibling had overlap then we would've already merged with it, so I think both cases just need to check the next entry if we extended past this one.

[kevans]

As pointed out: merge upwards as needed. We may have consumed multiple regions
with the new addition, so grab as many as we can then fill the hole if needed.

This has been lightly tested in userland, and things looked generally OK... I
tested a couple of scenarios to try and hit every branch.

[kevans]

Take flags into account when merging up

[mhorne]

LGTM

sys/kern/subr_physmem.c

291

358–362

Just to confirm, even when nend == rend, merge_upper_regions() might have work to do?

[kevans]

sys/kern/subr_physmem.c

358–362

Ah, no, good catch; I'll simplify this to nend > rend since this won't do anything useful for either statements. If we had upper region to merge with the end not moving, we failed with an earlier addition.