Andreas Färber <address@hidden> writes:
Am 09.06.2011 um 14:23 schrieb Gerd Hoffmann:
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.
Do we? The pc87312 is the only instance which changes those
settings at runtime, so they should not get out-of-sync even if they
are write-only for the pc87312.
The devices need to register the I/O ports for sure. No one else
knows
what functions to use.
So we either need your generic set_state callback or my explicit
helper functions to invoke that.
Are you okay with
those parts if we move just the VMState to pc87312? That feels
wrong.
I'd keep everything (iobase, irq, enabled state) in pc87312, so the
isa vmstate doesn't need any updates. The pc87312 actually applies
the configuration, so this doesn't feel wrong to me ...
Feels weird to me.
A device on a real ISA bus decodes whatever addresses it likes, and
raises whatever interrupt lines it likes.
Of course, the thing within the Super I/O isn't a real ISA bus, it
just
looks like one to software. Not that there's much to look at with
ISA.
Do we have any ordering guarantee that the isa devices were loaded
prior
to the pc87312 post hook?
I don't think so. Juan?
In that case it won't work (out-of-sync) and we shouldn't introduce
VMState for pc87312 at all imo. In theory we'd probably need a
pc87312-
owned bus to put the devices on but then I don't see how to reuse the
existing isa devices.
Err, which device provides your ISA bus if not pc87312?