Paolo Bonzini <pbonz...@redhat.com> writes: > Il 15/05/2013 16:28, Markus Armbruster ha scritto: >> Sorry for the delay, I was off for a few days. >> >> Anthony Liguori <aligu...@us.ibm.com> writes: >> >>> Paolo Bonzini <pbonz...@redhat.com> writes: >>> >>>> This reverts commit 9953f8822cc316eec9962f0a2858c3439a80adec. >>>> While Markus's analysis is entirely correct, there are 1.6 patches >>>> that fix the bug for real and without requiring machine type hacks. >>>> Let's think of the children who will have to read this code, and >>>> avoid a complicated mess of semantics that differ between <1.5, >>>> 1.5, and >1.5. >>>> >>>> Conflicts: >>>> hw/i386/pc_piix.c >>>> hw/i386/pc_q35.c >>>> include/hw/i386/pc.h >>>> >>>> Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> [...] >>>> diff --git a/hw/block/pc_sysfw.c b/hw/block/pc_sysfw.c >>>> index aad8614..4f17668 100644 >>>> --- a/hw/block/pc_sysfw.c >>>> +++ b/hw/block/pc_sysfw.c >> >> I'm afraid you forgot to delete variable >> pc_sysfw_flash_vs_rom_bug_compatible. > > Oops, thanks. > >>>> @@ -209,7 +209,7 @@ void pc_system_firmware_init(MemoryRegion *rom_memory) >>>> * TODO This device exists only so that users can switch between >>>> * use of flash and ROM for the BIOS. The ability to switch was >>>> * created because flash doesn't work with KVM. Once it does, we >>>> - * should drop this device for new machine types. >>>> + * should drop this device. >>>> */ >>>> sysfw_dev = (PcSysFwDevice*) qdev_create(NULL, "pc-sysfw"); >>>> >> >> Why did you change the comment? > > Because we agreed on the way forward for the flash patches, and it will > remove the need for (a) changes to machine types; (b) pc_sysfw in > general. The device will be created iff a -pflash or -drive if=pflash > option is provided. Thus in principle you could use -M pc-0.12 with > -pflash and it will work.
Yes, that's the way forward, and yes, that means we'll have no use for the "pc-sysfw" dummy device on new machine types. But why can we retroactively delete it from existing machine types?