Andreas Färber <andreas.faer...@web.de> writes: > Hi, > > 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? >>> How do BIOS config changes work on a PC? Which qdev would be >>> responsible >>> for saving their state? >> >> They are not re-configurable at runtime. I think even on real >> hardware you usually can only enable/disable devices, not change the >> configuration. > > I'm positive they are configurable by the BIOS, that's why I called it > "ISA reconfigurability" (not "Weird workarounds for PReP") and thought > about VMState in the first place. Yes, software-configurable ISA devices are fairly common. [...]
