[Qemu-devel] [Bug 1825207] Re: fw_cfg_machine_reset destroys user bootorder setting

[Laszlo Ersek \(Red Hat\)]

This bug report is invalid, for a less important reason and for a more
important reason.

(1) The less important reason is that "/address@hidden/address@hidden" is a 
string that
would never be generated by QEMU, as a bootorder entry. QEMU places
specific OpenFirmware device paths into the "bootorder" fw_cfg file.
Only SeaBIOS uses patterns like "address@hidden", for matching.

The suggestion in the SeaBIOS wiki at
<https://www.seabios.org/Runtime_config>, namely:

"However, it's safe to just copy and paste the pattern into bootorder."

is wrong, generally speaking. It might work if we consider SeaBIOS
exclusively -- in that SeaBIOS would manage to parse those entries --,
but they are invalid if we consider QEMU (not to mention OVMF).

(2) But, point (1) doesn't even matter much. The more important reason
why this report is invalid is that the "bootorder" fw_cfg file is under
the sole ownership of QEMU. "docs/specs/fw_cfg.txt" explains, in section
"Externally Provided Items":

"""
Use of names not beginning with "opt/" is potentially dangerous and
entirely unsupported.  QEMU will warn if you try.
"""

And that matches reality, on my end:

$ qemu-system-x86_64 -fw_cfg 
name=bootorder,string='/address@hidden/address@hidden'
qemu-system-x86_64: -fw_cfg 
name=bootorder,string=/address@hidden/address@hidden: warning: externally 
provided fw_cfg item names should be prefixed with "opt/"


The right way for controlling boot order is to use "bootindex=N" properties 
with the storage front-end devices. For exampe:

...
-device virtio-blk-pci,drive=system-disk,bootindex=1 \
-device scsi-cd,drive=installer-iso,bus=scsi0.0,bootindex=2 \
...

** Changed in: qemu
       Status: New => Invalid

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1825207

Title:
  fw_cfg_machine_reset destroys user bootorder setting

Status in QEMU:
  Invalid

Bug description:
  Demonstrated against 2.11 (ubuntu bionic 1:2.11+dfsg-1ubuntu7.12) and
  3.1 (as built under bionic from the 1:3.1+dfsg-2ubuntu3 source
  package) although the code hasn't changed between them and github
  master also appears to have this same code branch.

  What I was trying to do: select a boot disk using `-fw_cfg
  name=bootorder,string=/address@hidden/address@hidden based on the qemu and 
seabios
  documentation.  (Why do I want to do that? using qemu for installer
  testing for a specific kind of real machine and need to match the bios
  boot order.)

  What happened instead: same search-based boot order that I get without
  that option.  Also, /sys/firmware/qemu_fw_cfg/by_name/bootorder/raw is
  empty and .../size is "0".

  Brutal work around that did a useful thing:

  --- qemu-3.1+dfsg.orig/hw/nvram/fw_cfg.c
  +++ qemu-3.1+dfsg/hw/nvram/fw_cfg.c
  @@ -869,8 +869,10 @@ static void fw_cfg_machine_reset(void *o
       FWCfgState *s = opaque;
       char *bootindex = get_boot_devices_list(&len);
   
  +#if 0
       ptr = fw_cfg_modify_file(s, "bootorder", (uint8_t *)bootindex, len);
       g_free(ptr);
  +#endif
   }

  This change allowed the boot to work (so my bootorder setting was
  making it to seabios) and also showed up explicitly in
  /sys/firmware/qemu_fw_cfg.

  I don't know if fw_cfg_modify_file is intended to append rather than
  replace, but it doesn't; based on the seabios "Runtime_config" docs
  which suggest "look at the Searching bootorder for output and paste
  that into the bootorder file" I'd instead just have it only fill in
  bootorder if there's *no* existing setting, since a user can read out
  the defaults and copy them in as described if they want the fallback,
  but that's just from my interpretation of the docs.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1825207/+subscriptions