On 29/11/2017 15:47, Juergen Gross wrote: > On 29/11/17 15:44, Paolo Bonzini wrote: >> In either case, you would have a new option ROM. It could either be >> very simple and similar to multiboot.S, or it could be larger and do the >> same task as xen-pvh.S and enlighten_pvh.c (then get the address of >> startup_32 or startup_64 from FW_CFG_KERNEL_ENTRY and jump there). The >> ugly part is that the option ROM would have to know more details about >> what it is going to boot, including for example whether it's 32-bit or >> 64-bit, so I don't really think it is a good idea. > > As grub2 doesn't have to know, qemu shouldn't have to know either. That would be exactly what linuxboot-dma.c does already, but it's slower than PVH because Linux has to uncompress itself. The above thought experiment would make QEMU able to boot a PVH kernel without any changes to Linux. Paolo