qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Markus Armbruster
Subject: Re: [Qemu-devel] [RFC v4 03/12] isa: Provide set_state callback
Date: Thu, 09 Jun 2011 18:04:58 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Andreas Färber <address@hidden> 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.

[...]



reply via email to

[Prev in Thread] Current Thread [Next in Thread]