summaryrefslogtreecommitdiff
path: root/migration/fd.c
diff options
context:
space:
mode:
authorGreg Kurz <groug@kaod.org>2021-05-21 18:07:35 +0200
committerDavid Gibson <david@gibson.dropbear.id.au>2021-06-03 13:22:06 +1000
commit3bf0844f3be77b24cc8f56fc8df9ff199f8324cb (patch)
tree436f12347213d4ed4c8ddcde6bae9759338b59a2 /migration/fd.c
parentf2fac71d81de902b43d55060541b7ba9c9eacda4 (diff)
downloadqemu-3bf0844f3be77b24cc8f56fc8df9ff199f8324cb.zip
spapr: Don't hijack current_machine->boot_order
QEMU 6.0 moved all the -boot variables to the machine. Especially, the removal of the boot_order static changed the handling of '-boot once' from: if (boot_once) { qemu_boot_set(boot_once, &error_fatal); qemu_register_reset(restore_boot_order, g_strdup(boot_order)); } to if (current_machine->boot_once) { qemu_boot_set(current_machine->boot_once, &error_fatal); qemu_register_reset(restore_boot_order, g_strdup(current_machine->boot_order)); } This means that we now register as subsequent boot order a copy of current_machine->boot_once that was just set with the previous call to qemu_boot_set(), i.e. we never transition away from the once boot order. It is certainly fragile^Wwrong for the spapr code to hijack a field of the base machine type object like that. The boot order rework simply turned this software boundary violation into an actual bug. Have the spapr code to handle that with its own field in SpaprMachineState. Also kfree() the initial boot device string when "once" was used. Fixes: 4b7acd2ac821 ("vl: clean up -boot variables") Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1960119 Cc: pbonzini@redhat.com Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <20210521160735.1901914-1-groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Diffstat (limited to 'migration/fd.c')
0 files changed, 0 insertions, 0 deletions