[Note cc: Jordan, who added flash to x86 in commit bd183c79] Peter Maydell <peter.mayd...@linaro.org> writes:
> These patches implement migration support for pflash_cfi01. > The first patch just drops some useless state so we don't > have to think about it for migration. > > NB that pflash_cfi01 is used in the x86 pc model. I think this > means that migration while the BIOS is accessing the flash > wouldn't have worked properly. Since migration from a device > with no vmstate to one with vmstate works OK this shouldn't > break cross-version migration. However x86 maintainers may > wish to review and confirm this for themselves... x86 maintainers may wish to *switch it off* until it's done fully and properly, by setting "pc-sysfw" property "rom_only" to 1. x86 flash use was added in series "[PATCH v10 0/8] PC system flash support", commit 4732dcaf..1b89fafe, v1.1. Core code is pc_system_firmware_init(). Works as follows, as far as I can tell: * Create a "pc-sysfw" device with default properties. This device does nothing in particular, and is *not* guest-visible. It appears to be used just as a property container. * If (default) property "rom_only" is non-zero, map the BIOS ROM the traditional way. Get its contents from the file named by -bios, default "bios.bin". This is the case for isapc as well as pc-1.0 and older. * Else, if KVM is enabled, putting BIOS in flash doesn't actually work (KVM restriction), so force "rom_only" to one, and map the BIOS ROM the traditional way, as above. Fatal error if the user defined drive if=pflash,bus=0,unit=0, because that's valid only when we're using flash for the BIOS ROM. I understand this case is meant to go away when the KVM restriction gets lifted. * Else, map the BIOS ROM as flash device. Note: for now, this case applies only when KVM is disabled. - If the user did not define said pflash drive, create one with BIOS ROM contents (get it the same way as above). Failure is fatal. - Create a "cfi.pflash01" block device backed by the pflash drive. What does this mean? 1. The "pc-sysfw" device is mostly harmless. 2. Enabling/disabling KVM is guest-visible! With KVM disabled, you get a flash memory device. With KVM enabled, you get a ROM. Not good; KVM should be as transparent as possible to the guest. I raised this issue last August, Jordan told me he's working on it[*], and I let the matter rest then. That was a mistake. [*] http://lists.nongnu.org/archive/html/qemu-devel/2012-08/msg03178.html