loader: allocate the memdisk decompression buffer as EfiLoaderData

[olivier]

Summary

A memdisk= image reaches the kernel as a preloaded md(4), so its pages must be in physmap.
Add_efi_map_entries() admits only EFI_MD_TYPE_CODE/DATA/FREE, so EfiReservedMemoryType gets no direct map and mdstart_preload() faults at base + mediasize - 512.
EfiLoaderData is EFI_MD_TYPE_DATA, already used for the kernel and modules.

Test Plan

Booting a 2 GB disk image with memdisk=<url> panics in mdstart_preload()
when the image is served xz-compressed. The same image served
uncompressed boots fine.

he fault is always a read of the final 512-byte sector of the registered
region: fault_addr == preload_base + mediasize - 512. The loader registers a
region whose span matches mediasize exactly, but the last sector of it is not
mapped, so the first UFS read that touches it faults.

Reproduced 3/3 on the compressed path, 0/1 on the uncompressed path.

[imp]

Hmmm, reserved is the right type for nvdimm, but it does pmap_large_map() instead of mpam_map(), but both of those should yield the same results...

So help me understand... Can you do a bootverbose w/o the patch? Why would the uncompressed one work, but the compressed one fail after decompression...

But also do a 'show' command at the OK prompt before you do a boot -v so I can see the md.0.xxxx values and compare them against the phys_avail.