Hi Phil, On 07/02/19 02:12, Philippe Mathieu-Daudé wrote: > The pflash device lacks a reset() function. > When a machine is resetted, the flash might be in an > inconsistent state, leading to unexpected behavior: > https://bugzilla.redhat.com/show_bug.cgi?id=1678713 > Resolve this issue by adding a DeviceReset() handler. > > Fix also two minor issues, and clean a bit the codebase. > > Since v1: https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg00962.html > - addressed Laszlo review comments > > Maintainers spam list from: > ./scripts/get_maintainer.pl -f $(git grep -El > '(pflash_cfi01_register|TYPE_PFLASH_CFI01)') > > Regards, > > Phil. > > Philippe Mathieu-Daudé (9): > hw/block/pflash_cfi01: Removed an unused timer > hw/block/pflash_cfi01: Use the correct READ_ARRAY value > hw/block/pflash_cfi01: Extract pflash_mode_read_array() > hw/block/pflash_cfi01: Start state machine as READY to accept commands > hw/block/pflash_cfi01: Add the DeviceReset() handler > hw/block/pflash_cfi01: Simplify CFI_QUERY processing > hw/block/pflash_cfi01: Improve command comments > hw/block/pflash_cfi01: Replace DPRINTF by qemu_log_mask(GUEST_ERROR) > hw/block/pflash_cfi01: Hold the PRI table offset in a variable > > hw/block/pflash_cfi01.c | 140 +++++++++++++++++++++------------------- > hw/block/trace-events | 1 + > 2 files changed, 74 insertions(+), 67 deletions(-) >
I'll do some regression-tests with this, using OVMF and ArmVirtQemu. I don't think I can usefully review the patches without getting lost in the related spec(s), and I don't have capacity for that. Until I have regression test results, one question: are the changes to the device model transparent with regard to migration? (You are not introducing any compat properties.) Thanks! Laszlo
