Hi Peter, On 4/12/21 12:11 PM, Peter Maydell wrote: > On Sat, 10 Apr 2021 at 16:15, Peter Maydell <peter.mayd...@linaro.org> wrote: >> I do wonder if the right fix to that would be to make TYPE_MACHINE >> be a subtype of TYPE_DEVICE, though -- machines not being subtypes >> of device has other annoying effects, like their not having reset >> methods or being able to register vmstate structs. > > I wasn't quite right about this -- turns out that machines can > have a reset method, but it is a weird special case method > MachineClass::reset that isn't like device reset. (We use it > in a few machine types; if implemented, it is responsible for > calling qemu_devices_reset() to kick off device reset. Probably > MachineClass ought to implement TYPE_RESETTABLE_INTERFACE > instead.)
TIL MachineClass::reset(). - hw/hppa/machine.c - hw/i386/pc.c Used to reset CPUs manually because CPUs aren't sysbus-reset. - hw/i386/microvm.c Removing the microvm_fix_kernel_cmdline() call which is suspicious at reset (should be enough once in realize time), the is the same previous "Used to reset CPUs manually ..." - hw/ppc/pnv.c "Reset BMC simulator" seems a legitimate case of machine reset. Next is 'fdt = pnv_dt_create()'. So guest has changed hardware state and we need to refresh the DT for the next guest boots. Could be. - hw/ppc/spapr.c Similar previous "Used to reset CPUs manually ..." Similar previous "update DT after hardware physically changed". Am I correct than half of these handlers code is to kludge the fact that CPU aren't reset such device reset? Regards, Phil.
