Re: [Qemu-devel] [PATCH v4 6/7] Make the kernel image in the fw_cfg DMA interface bootable

[Laszlo Ersek]

On 10/01/15 14:16, Marc Marí wrote:
> Add an entry to the bootorder file with name "vmlinux".
> Give this entry more priority than the romfile.
> 
> Signed-off-by: Marc Marí <address@hidden>
> ---
>  hw/i386/pc.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 81d93b4..c4c51f7 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -1012,8 +1012,10 @@ static void load_linux(PCMachineState *pcms,
>      fw_cfg_add_bytes(fw_cfg, FW_CFG_SETUP_DATA, setup, setup_size);
>  
>      option_rom[nb_option_roms].name = "linuxboot.bin";
> -    option_rom[nb_option_roms].bootindex = 0;
> +    option_rom[nb_option_roms].bootindex = 1;
>      nb_option_roms++;
> +
> +    add_boot_device_path(0, NULL, "vmlinux");
>  }
>  
>  #define NE2000_NB_MAX 6
> 

Where does this idea come from?

This will yet again break the invariant that the bootorder fw_cfg file
is a list of OpenFirmware device paths.

(The other annoying offender being "HALT", which caused me huge grief in
the OVMF OpenFirmware devpath parser parser, when libvirt decided that
"-boot strict=on" would become default.)

OVMF (and AAVMF) have been able to boot kernels directly from fw_cfg for
quite some time now, without the above change. They look at the fw_cfg
key 0x0008 (FW_CFG_KERNEL_SIZE). Direct kernel boot is being requested
iff the (little endian encoded) uint32 value is nonzero.

In QEMU, this role of FW_CFG_KERNEL_SIZE is true for:

- arm_load_kernel_notify() [hw/arm/boot.c], relied upon by AAVMF,

- load_multiboot() [hw/i386/multiboot.c] and
  load_linux() [hw/i386/pc.c], relied upon by OVMF,

- "hw/ppc/mac_newworld.c", "hw/ppc/mac_oldworld.c", "hw/sparc/sun4m.c",
  and "hw/sparc64/sun4u.c", relied upon by whatever boot firmware they
  have.

Why is this necessary for SeaBIOS?

... I can see the function bootprio_find_vmlinux(), in SeaBIOS patch

  [PATCH v4 2/2] Boot Linux using QEMU fw_cfg DMA interface

Given that direct kernel boot is always expected to take priority over
anything else (which is ensured by this QEMU patch too), can
bootprio_find_vmlinux() in SeaBIOS just look at the same fw_cfg key
(0x0008)?

I checked the QEMU_CFG_* macros in "src/fw/paravirt.c", and I think when
SeaBIOS boots an fw_cfg kernel *now*, it doesn't do it with its own
implementation; it probably launches the "linuxboot.bin" oprom (from
QEMU -- "pc-bios/optionrom/linuxboot.S").

I vaguely recall that this assembly code has been deemed unwieldy for
implementing the DMA interface (and I fully agree), which is why the
above-referenced SeaBIOS patch adds the capability to SeaBIOS itself. I
agree with that too.

But, instead of messing up the "bootorder" fw_cfg file, can
bootprio_find_vmlinux() look at the non-nullity of the
QEMU_CFG_KERNEL_SIZE key? Such as:

- read four bytes from under the fw_cfg selector QEMU_CFG_KERNEL_SIZE
  (0x0008),
- if it is zero,    return -1 --> no kernel boot requested,
- if it is nonzero, return  0 --> which means "top priority".

In other words, I agree with:

> -    option_rom[nb_option_roms].bootindex = 0;
> +    option_rom[nb_option_roms].bootindex = 1;

in this patch, but I disagree with:

> +    add_boot_device_path(0, NULL, "vmlinux");

Thank you
Laszlo