Re: [Qemu-devel] [RFC v4 03/12] isa: Provide set_state callback

[Andreas Färber]

Hi,

Am 09.06.2011 um 12:39 schrieb Gerd Hoffmann:

> > +const VMStateDescription vmstate_isa_device = {
> > +    .name = "ISADevice",
> > +    .version_id = 1,
> > +    .minimum_version_id = 1,
> > +    .fields = (VMStateField []) {
> > +        VMSTATE_BOOL(enabled, ISADevice),
> > +        VMSTATE_END_OF_LIST()
> > +    }
> > +};
>
> That alone isn't enougth.  You also need to save iobase and irq.

Here it becomes tricky: the enabling was done at ISA level on your  
suggestion, but the iobase and isairq are kept in the ISADevices'  
state. Duplicates are however kept at ISA level, it's fairly ugly.

I would prefer to save the state where it is stored. In this case  
enabled is store at ISADevice level, so I added the VMState for it here.

Btw is 1 correct here or should an initial version be 0?

> And have a pre-load callback which disables the device + a post-load  
> callback which re-enables them with the new settings.

Right.

> I get the feeling that doing all this in the pc87312 emulation is  
> easier as it needs to have this logic anyway for config register  
> writes and you can probably reuse the code for loadvm pre- and  
> postprocessing.


Well, I wasn't looking for the easiest way but for the proper way. I  
don't want to let pc87312-internal state get out-of-sync with that of  
the aggregated devices. So we still need the qdev getters, and we  
still need each device to handle enabling/disabling itself. Are you  
okay with those parts if we move just the VMState to pc87312? That  
feels wrong.

Do we have any ordering guarantee that the isa devices were loaded  
prior to the pc87312 post hook?

How do BIOS config changes work on a PC? Which qdev would be  
responsible for saving their state?

Andreas