|
From: | Gerd Hoffmann |
Subject: | Re: [Qemu-devel] [RFC v4 03/12] isa: Provide set_state callback |
Date: | Thu, 09 Jun 2011 14:23:42 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110419 Red Hat/3.1.10-1.el6_0 Thunderbird/3.1.10 |
Hi,
Btw is 1 correct here or should an initial version be 0?
I think for sub-structs it doesn't matter at all, only for top-level vmstates.
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.
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 ...
Do we have any ordering guarantee that the isa devices were loaded prior to the pc87312 post hook?
I don't think so. Juan?
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.
cheers, Gerd
[Prev in Thread] | Current Thread | [Next in Thread] |