Re: [Qemu-devel] [RFC v2 00/10] ISA reconfigurability v2

[Andreas Färber]

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