You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As OS kernels are quite often particular about memory layout, GDT, IRQs, etc., they often choose to set these things up themselves and not rely on the bootloader. In addition, using PVH start_info [1] is now kind of an industry standard when booting guest images in VMS (e.g. [2]).
Would it be in scope of this project to support this "PVH header + chain load a realmode next stage" loading flow? I.e. load initrd, prepare PVH start_info (basically, the memory map, initrd address/len, rsdp address), and jump into the next stage? If so, I'll hack together a prototype PR... (for MBR/BIOS only, I see no use for UEFI in a VM, sorry).
Hello!
As OS kernels are quite often particular about memory layout, GDT, IRQs, etc., they often choose to set these things up themselves and not rely on the bootloader. In addition, using PVH start_info [1] is now kind of an industry standard when booting guest images in VMS (e.g. [2]).
Would it be in scope of this project to support this "PVH header + chain load a realmode next stage" loading flow? I.e. load initrd, prepare PVH start_info (basically, the memory map, initrd address/len, rsdp address), and jump into the next stage? If so, I'll hack together a prototype PR... (for MBR/BIOS only, I see no use for UEFI in a VM, sorry).
Thanks,
U.L.
[1] https://github.com/Xilinx/xen/blob/master/xen/include/public/arch-x86/hvm/start_info.h
[2] https://www.cloudhypervisor.org/docs/prologue/quick-start/
The text was updated successfully, but these errors were encountered: