]> git.proxmox.com Git - mirror_qemu.git/commit
spapr: Don't hijack current_machine->boot_order
authorGreg Kurz <groug@kaod.org>
Fri, 21 May 2021 16:07:35 +0000 (18:07 +0200)
committerDavid Gibson <david@gibson.dropbear.id.au>
Thu, 3 Jun 2021 03:22:06 +0000 (13:22 +1000)
commit3bf0844f3be77b24cc8f56fc8df9ff199f8324cb
tree436f12347213d4ed4c8ddcde6bae9759338b59a2
parentf2fac71d81de902b43d55060541b7ba9c9eacda4
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>
hw/ppc/spapr.c
include/hw/ppc/spapr.h