add support for MEMDISK loaded disk images to bootloader and md

[russor_ruka.org]

Summary

MEMDISK is part of the Syslinux project; it loads disk images into memory, sets an int 13h hook and then does a BIOS boot from the image; this can be used as part of a PXE boot environment to load installer disks, however the disks are not accessible from inside the FreeBSD kernel because it doesn't access disks through BIOS APIs.

This patch detects the disk images in the loader, and passes their address and length as a driver hint. When the md driver sees the hint, it maps the image, and presents it to the system.

It seems like FreeBSD 8.x used mfsroot on installer images, which would work with MEMDISK, but all releases since then stopped in favor of mounting the cdrom or memory stick directly. PXE booting with the installer root mounted via NFS could probably also work, but is a more involved setup than loading an image.

I'm not sure if the printf'ing here is too verbose (probably).

Test Plan

I've tested this in VMWare with a PXE boot system, as well as on a recent Ryzen 4000G system.

[imp]

stand/i386/libi386/biosmemdisk.c

63

This isn't a mBFT table, but it might be... maybe this printf is too verbose

96

This is also confusing, but may not be too verbose

sys/dev/md/md.c

2077

Maybe a for loop is better here. It seems clearer

2084

Should print the md unit?

2086

Would be better to print this all on one line

[russor_ruka.org]

address some of the comments

[russor_ruka.org]

Thanks for the quick feedback. I've adjusted things a bit. Let me know what you think of the changes to the printfs in bios_memdisk.c; maybe they should just go away as they probably aren't very useful... and they're hard to see on a normal config anyway (they get output before the loader menu, the loader doesn't lets you scroll back to see them, and release images don't setup loader on the serial console).

Do you have advice for any other reviewers or mailing lists I should ask to look at this?

Thanks!

stand/i386/libi386/biosmemdisk.c

96

This might still be confusing, but I tweaked it a bit.

sys/dev/md/md.c

2084

I don't actually have the md unit here (it'll be assigned in md_preloaded), and md_preloaded also outputs some of the same info, so I put the physical address, and hint number in the name.

[imp]

Thanks for the updates... I like this...

Any chance this could also be leveraged for the UEFI memory disks? I've not had a chance to look into them in detail, other than to know they exist...

[russor_ruka.org]

I hadn't heard of UEFI memory disks before, so you're ahead of me there. If the memory is physically contiguous, and there's a way to get the base address and length through UEFI apis, the md driver changes should work, and we'd need UEFI loader changes to detect the memory, and hint it to the driver.

I did find some specifications for the UEFI ram disk protocol, which takes a base address and a length to setup a memory disk; and some background reading says UEFI is using identity paging. But I'm not experienced with UEFI to know if one can easily enumerate disks and get the setup data back. Also, I would wonder about how the memory backing the disk is marked in the memory map for the kernel. Memdisk marks it as not available for use, and these loader changes are checking pretty well that it's memdisk, so I think we can count on that; but perhaps UEFI memory disk loaders may intend for the OS to reuse the memory once booted?

From what I can tell, nobody is using UEFI to PXE boot ISOs; instructions for Linux installers that I've seen involves extracting the kernel and initrd images out of ISOs and loading those as individual files. Memdisk is BIOS only, and I haven't seen anything like it for UEFI.