hw/nvram/fw_cfg: update bootorder to fix SeaBIOS bootup failure

[PATCH v2 0/2] hw/nvram/fw_cfg: update bootorder to fix SeaBIOS bootup failure

Posted by Dongli Zhang 4 weeks ago

During system reset, and only during system reset, QEMU updates the
"bootorder" and "bios-geometry" entries in fw_cfg based on the contents of
"fw_boot_order" and "fw_lchs". After the guest VM boots, the firmware
(e.g., SeaBIOS) can read the boot order from fw_cfg and boot from the disk
at the top of the list.

The reset handler fw_cfg_machine_reset() is invoked either implicitly
during instance creation or explicitly by the user via HMP/QMP.

However, users may attach or detach disks while the VM is in the prelaunch
state. Because there is no implicit reset when transitioning from prelaunch
to running, the "bootorder" and "bios-geometry" data in fw_cfg can become
stale. As a result, the firmware may be unable to locate the correct disk
to boot from.

Here is an example that demonstrates the bug.

1. Create a QEMU instance with a virtio-scsi HBA and keep it in the
prelaunch state. Use SeaBIOS rather than UEFI.

-device virtio-scsi-pci,id=scsi0,num_queues=4 \
-S \

2. First, attach the boot disk, then attach the secondary disk.

(qemu) drive_add 0 file=boot.qcow2,if=none,id=drive0
(qemu) device_add scsi-hd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=1,bootindex=1
(qemu) drive_add 0 file=secondary.qcow2,if=none,id=drive1
(qemu) device_add scsi-hd,drive=drive1,bus=scsi0.0,channel=0,scsi-id=0,lun=2,bootindex=-1

3. Start the VM from the prelaunch state. Because the "bootorder" and
"bios-geometry" data in fw_cfg is stale, SeaBIOS attempts to boot from the
secondary disk only once and then stops. As a result, the VM fails to boot.

One possible workaround is to require QEMU users to explicitly issue a
system_reset before starting a guest VM from the prelaunch state, if any
disks have been attached or detached.

Another option is to address the issue in SeaBIOS. Nowadays, SeaBIOS
attempts to boot from only a single disk. We could enhance SeaBIOS to try
multiple disks in order until boot succeeds.

Another option is to update "bootorder" and "bios-geometry" everywhere
disks are attached or detached. This may require identifying the relevant
functions across multiple device types, such as SCSI, NVMe, virtio-blk, and
IDE.

This commit fixes the issue in QEMU by ensuring that "bootorder" and
"bios-geometry" are always updated when QEMU transitions from the prelaunch
state to running.

According to runstate_transitions_def[], RUN_STATE_PRELAUNCH is allowed to
transition to four states. Only the transition to RUN_STATE_RUNNING
requires updating "bootorder" and "bios-geometry".

v1: https://lore.kernel.org/qemu-devel/20260225220556.11049-1-dongli.zhang@oracle.com

v1 -> v2:
  - Add new runstate tranisition notifier to track transition from
    prelaunch to running.


Dongli Zhang (2)
  system/runstate: add runstate transition notifier
  hw/nvram/fw_cfg: update bootorder and bios-geometry before launching

 hw/nvram/fw_cfg.c         | 31 +++++++++++++++++++++++++++++--
 include/hw/nvram/fw_cfg.h |  1 +
 include/system/runstate.h |  8 ++++++++
 system/runstate.c         | 25 +++++++++++++++++++++++++
 4 files changed, 63 insertions(+), 2 deletions(-)

Thank you very much!

Dongli Zhang

Re: [PATCH v2 0/2] hw/nvram/fw_cfg: update bootorder to fix SeaBIOS bootup failure

Posted by Gerd Hoffmann 3 weeks, 6 days ago

  Hi,

> 1. Create a QEMU instance with a virtio-scsi HBA and keep it in the
> prelaunch state. Use SeaBIOS rather than UEFI.
> 
> -device virtio-scsi-pci,id=scsi0,num_queues=4 \
> -S \
> 
> 2. First, attach the boot disk, then attach the secondary disk.
> 
> (qemu) drive_add 0 file=boot.qcow2,if=none,id=drive0
> (qemu) device_add scsi-hd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=1,bootindex=1
> (qemu) drive_add 0 file=secondary.qcow2,if=none,id=drive1
> (qemu) device_add scsi-hd,drive=drive1,bus=scsi0.0,channel=0,scsi-id=0,lun=2,bootindex=-1
> 
> 3. Start the VM from the prelaunch state. Because the "bootorder" and
> "bios-geometry" data in fw_cfg is stale, SeaBIOS attempts to boot from the
> secondary disk only once and then stops. As a result, the VM fails to boot.
> 
> One possible workaround is to require QEMU users to explicitly issue a
> system_reset before starting a guest VM from the prelaunch state, if any
> disks have been attached or detached.

Requiring a system_reset looks sensible to me.  Neither seabios nor ovmf
have hotplug support.  So if you expect the firmware pick up any new
devices after hot-plugging them it is IMHO a very good idea to force a
full re-initialization via system_reset for robustness reasons.

take care,
  Gerd

Re: [PATCH v2 0/2] hw/nvram/fw_cfg: update bootorder to fix SeaBIOS bootup failure

Posted by Dongli Zhang 3 weeks, 5 days ago

Hi Gerd,

On 3/11/26 4:34 AM, Gerd Hoffmann wrote:
>   Hi,
> 
>> 1. Create a QEMU instance with a virtio-scsi HBA and keep it in the
>> prelaunch state. Use SeaBIOS rather than UEFI.
>>
>> -device virtio-scsi-pci,id=scsi0,num_queues=4 \
>> -S \
>>
>> 2. First, attach the boot disk, then attach the secondary disk.
>>
>> (qemu) drive_add 0 file=boot.qcow2,if=none,id=drive0
>> (qemu) device_add scsi-hd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=1,bootindex=1
>> (qemu) drive_add 0 file=secondary.qcow2,if=none,id=drive1
>> (qemu) device_add scsi-hd,drive=drive1,bus=scsi0.0,channel=0,scsi-id=0,lun=2,bootindex=-1
>>
>> 3. Start the VM from the prelaunch state. Because the "bootorder" and
>> "bios-geometry" data in fw_cfg is stale, SeaBIOS attempts to boot from the
>> secondary disk only once and then stops. As a result, the VM fails to boot.
>>
>> One possible workaround is to require QEMU users to explicitly issue a
>> system_reset before starting a guest VM from the prelaunch state, if any
>> disks have been attached or detached.
> 
> Requiring a system_reset looks sensible to me.  Neither seabios nor ovmf
> have hotplug support.  So if you expect the firmware pick up any new
> devices after hot-plugging them it is IMHO a very good idea to force a
> full re-initialization via system_reset for robustness reasons.
> 

Regarding "Neither seabios nor ovmf have hotplug support", we are not using
hotplug with SeaBIOS or OVMF in this scenario.

This is a cold-plug operation performed during QEMU prelaunch state, before any
system software starts running.

(1) Create QEMU with "-S" at prelaunch.
(2) Attach disks.
(3) "cont" for QEMU.

In other words, we cold-plug the new disks before SeaBIOS starts.

However, because the "bootorder" data from QEMU is stale, SeaBIOS cannot
construct the correct boot order once it begins executing.

So this does not involve hotplug; it is purely cold-plug during prelaunch, prior
to SeaBIOS startup.

Therefore, would you mind helping confirm if to issue a system_reset manually is
still the best option so far?

Thank you very much!

Dongli Zhang

Re: [PATCH v2 0/2] hw/nvram/fw_cfg: update bootorder to fix SeaBIOS bootup failure

Posted by Gerd Hoffmann 3 weeks, 4 days ago

  Hi,

> Regarding "Neither seabios nor ovmf have hotplug support", we are not using
> hotplug with SeaBIOS or OVMF in this scenario.
> 
> This is a cold-plug operation performed during QEMU prelaunch state, before any
> system software starts running.
> 
> (1) Create QEMU with "-S" at prelaunch.
> (2) Attach disks.
> (3) "cont" for QEMU.
> 
> In other words, we cold-plug the new disks before SeaBIOS starts.
> 
> However, because the "bootorder" data from QEMU is stale, SeaBIOS cannot
> construct the correct boot order once it begins executing.

system_reset will fix that.

> Therefore, would you mind helping confirm if to issue a system_reset manually is
> still the best option so far?

Yes, I think so.  Specifically it has the advantage to work just fine
with already released qemu versions, and sending one extra command
between (2) + (3) should not be much of a problem for the management.

take care,
  Gerd