Am 07.06.2011 um 17:16 schrieb Gerd Hoffmann:
On 06/07/11 17:02, Andreas Färber wrote:
As suggested by Gerd, I've introduced a set_state() callback at ISA
level
and implemented it as required for pc87312.
This approach simplifies some things but currently has the drawback
that the
devices are disabled and potentially re-enabled for each register
write.
Doesn't the pc87312 keep track of the configured iobases and irqs?
So it should know whenever a register write changed something or
not ...
The original patch submission kept copies of the values in the pc87312
DeviceState.
I consider that redundant with the devices' DeviceState though and
removed it with my introduction of helpers that had access to the
devices' DeviceState in v1.
That access we have now lost in v2 (only the set_state callback has,
but that doesn't know its former state; disabling twice is expected to
succeed btw), so once set, the pc87312 has no clue about the current
property values.
Just wondering, if we're allowing to change qdev properties at runtime
here, don't these fields need to be considered for VMState? (cc'ing
Juan)
If I understand the theory of live migration correctly, then the
command line needs to be identical wrt devices on both machines - if
the migration source has executed firmware code changing the iobase
and the migration target resumes wherever the source was, they'd end
up with different DeviceState, right? Or are qdev properties
transmitted anyway? (not that I care for PReP but these are generic
ISA devices)
Interestingly, I don't see any VMState in parallel.c.
serial.c, fdc.c and ide/isa.c do have it, but I don't see iobase and
irq in there. Would having iobase and irq number defined as VMState
make reading them any easier?
Andreas