Re: [Qemu-devel] [FYI 4/4] prep: Quickfix for ioport

[Alexander Graf]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 04.01.2011, at 22:36, Andreas Färber wrote:

> Am 04.01.2011 um 21:57 schrieb Alexander Graf:
> 
>> On 27.12.2010, at 01:25, Andreas Färber wrote:
>> 
>>> Am 27.12.2010 um 01:11 schrieb Alexander Graf:
>>> 
>>>> Am 27.12.2010 um 00:28 schrieb Andreas Färber <address@hidden>:
>>>> 
>>>>> Am 14.12.2010 um 01:49 schrieb Andreas Färber:
>>>>> 
>>>>>> Workaround the following error:
>>>>>> 
>>>>>> qemu: hardware error: register_ioport_read: invalid opaque
>>>>> 
>>>>> I found out that this is a conflict with i8042 registering I/O port 
>>>>> 0x0092 in pckbd.c, too.
>>>>> Not sure what the proper fix should look like - add some qdev property to 
>>>>> ISAKBDState to disable the port?
>>>> 
>>>> Well, why does the PREP board have its own mapping there in the first 
>>>> place? It should be the same as a PC from a port pov, no?
>>> 
>>> Why does the i8042 controller have a System Control Port in the first place 
>>> rather than the 'pc' machine? :)
>>> 
>>> The PReP spec v1.1 has a Special Port 0x0092 that includes two bits of 
>>> significence - softreset and endian mode. So wherever the port is 
>>> registered, the latter behavior is board-specific and does not match 
>>> pckbd.c (A20 gate or HDD activity depending on bit numbering).
>>> 
>>> A similar issue arises between PReP machines: The ioport currently does not 
>>> allow using a different opaque for reads and writes to the same address. So 
>>> either we need to change ioport or create some inheritence/override 
>>> mechanism for port behavior.
>> 
>> Hmm - sounds to me like that register simply doesn't belong there then, so a 
>> split would be the correct solution. The alternative would be to have the 
>> keyboard controller create a bus that those bits send signals to. An x86 
>> system could then implement its A20 gate in x86 specific code while PREP 
>> could do its specific stuff.
> 
> Coincidentally there's a recent pckbd patch from Blue that resolves the 
> conflict. Feel free to review. :)

Ah, sorry :). Still catching up. Just now finished to watch news of the last 1 
1/2 weeks :).

> Any thoughts on the read vs. write port issue? Do we need to register both 
> ports in the base device and add hooks to the device state? Sounds 
> problematic VMState-wise, just like some of the qemu_irq constructs in the 
> ppc devices. (My prep_pci changes are still far from perfect, UniNorth has 
> similar issues I noticed.)

Well, the general idea is that a single IO always gets routed to the same 
device. I don't fully understand why you need separate handlers there tbh. Mind 
to explain this?


Alex

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)

iEYEARECAAYFAk0jlJcACgkQq7Wi27wfN1N/agCeL6hOC6c+DHjLQ7Q3uXsp1Clo
x94An0lSzs/kvXGynRy1y2UMmLwpltp1
=NkaJ
-----END PGP SIGNATURE-----