On 29/11/2017 15:25, Boris Ostrovsky wrote:
>>>> zeropage is x86/Linux-specific so we'd need some sort of firmware (like
>>>> grub) between a hypervisor and Linux to convert hvm_start_info to
>>>> bootparams.
>>> qemu?
>
> I think KVM folks didn't want to do this. I can't find the thread but I
> believe it was somewhere during Clear Containers discussion. Paolo?
QEMU is the right place to parse the ELF file and save it in memory.
You would have to teach QEMU to find the Xen note in ELF-format kernels
(just like it looks for the multiboot header), and use a different
option ROM ("pvhboot.c" for example).
However I don't like to bypass the BIOS; for -kernel, KVM starts the
guest with an option ROM (linuxboot-dma.c or multiboot.S in QEMU
sources) that takes care of boot.
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.
I actually like this patch, except that I'd get the e820 memory map from
fw_cfg (see the first part of
https://github.com/bonzini/qboot/blob/master/fw_cfg.c, and extract_e820
in https://github.com/bonzini/qboot/blob/master/main.c) instead of the
second module.
Thanks,
Paolo
>
>> But then it won't be using the PVH entry point, and would just use the
>> native one?
>>
>> My understanding was that the PVH shim inside of Linux will prepare a
>> zero-page when booted using the PVH entry point, and then jump into
>> the native boot path.
> Right, but that's not what Juergen's second option is. IIUIC with that
> option Linux starts with zeropage already prepared. No shim in the kernel.
