On Sun, 18 Feb 2024, Bernhard Beschow wrote:
This series attempts to make QEMU's south bridge families PIIX, ICH9, and VIA
82xx more self-contained by integrating IO port 92 like the originals do.
In QEMU, the IO port is currently instantiated as a dedicated device in common
PC code. While this works and even results in less code, it seems cleaner to
model the behavior of the real devices. For example, software running on the
Malta machine, which uses PIIX4, needs to take port 92 into account, even if it
doesn't use it (does it?). Moreover, the FDC37M81x used in the original Malta
machine provides a port 92 too, which can be activated. If QEMU implemented the
FDC37M81x more closely, one could check if Yamon (or any alternative boot
loader) deals correctly with these ports.
Maybe that's unlikely as this register is for controlling A20 line of
Intel CPUs so probably there's no use for it in a MIPS or PPC board but
I'm not sure if it may be used for something else.
Moving port 92 into the south bridges might also help with configuration-driven
machine creation. In such a scenario it is probably desirable if machine code
had less of its own idea of which devices it creates.
The direction is probably good as these chips have a pin for A20 control
and handle the register themselves but I'm not sure this series is the
right way. One immediate problem is that TYPE_PORT92 has state which is in
the migration stream so moving it elsewhere would break migration which
would need to be handled. Does this series handle that? I'm not sure it's
worth the effort though if it results in more comlex code. If the
migration issue is handled, then I think we should get rid of TYPE_PORT92
completely and just add the one reg and qemu_irq modeling the output pin
as qemu_gpio to the south bridge implementations directly, not embedding a
separate object for it as these south bridges may already have some io
region for ports and state where the reg can be stored so it could be
added there instead of just moving the TYPE_PORT92 there. But with the
migration issue it's probably easier to just leave it as it is now. Even
if this would model the real chip better, it would result in more code and
complexity in QEMU so not sure it's a good idea because of that.
Moving port 92 from
machine code into a potentially user-creaeable device (where it is part of per
datasheet) seems like a good direction. Of course, machine code still wires up
port 92 and I don't have a good idea on how to make this user-configurable.
Such insights might provide some input for discussions around
configuration-driven machine creation.
That's a generic problem for dynamic or declarative machine creation to
solve. Likely the machine description will also need to describe the
connections between devices, not just what devices to instantiate. So
that's not specific to port92. As we're not there yet it's also not urgent
to touch this port92 stuff.
Maybe I overestimate the migration issue as I'm not familiar with that so
if others think it's not an issue then I'm not against this series as it
would bring the model closer to the actual hardware but then go all the
way and get rid of TYPE_PORT92 and just implement it in the south bridges.
But due to how it's currently done and how that's now baked in because of
backward compatibility requrement for migration, I'm not sure it would
really simplify the code, so we may need to live with what we have now.
But let me know if I'm wrong and missed something.
Regards,
BALATON Zoltan
This series is structured as follows: Patch 1 moves TYPE_PORT92 into the isa
directory to make it reusable by other architectures. It also adds a
configuration switch. Patch 2 integrates TYPE_PORT92 into the PC south bridges
and adapts PC code accordingly. While at it, patch 3 cleans up wiring of the
A20 line with the keyboard controller. Patch 4 simply adds TYPE_PORT92 to the
VIA south bridges which is also needed when using the VIA south bridges in the
pc machine.
Testing done:
* `qemu-system-x86_64 -M {q35,pc},i8042={true,false} ...`
-> `info mtree` confirms port92 to be present iff i8042=true
* `make check`
* `make check-avocado`
* Start amigaone and pegasos2 machines as described in
https://patchew.org/QEMU/20240216001019.69a524e6...@zero.eik.bme.hu/
-> no regressions compared to master
Best regards,
Bernhard
Bernhard Beschow (5):
hw/isa/meson.build: Sort alphabetically
hw/i386/port92: Allow for TYPE_PORT92 to be embedded in devices
hw/isa: Embed TYPE_PORT92 in south bridges used in PC machines
hw/i386/pc: Inline i8042_setup_a20_line() and remove it
hw/isa/vt82c686: Embed TYPE_PORT92
include/hw/i386/pc.h | 7 +------
include/hw/input/i8042.h | 1 -
include/hw/isa/port92.h | 30 ++++++++++++++++++++++++++++++
include/hw/southbridge/ich9.h | 4 ++++
include/hw/southbridge/piix.h | 3 +++
hw/i386/pc.c | 21 ++++++++++++++-------
hw/i386/pc_piix.c | 9 +++++++--
hw/i386/pc_q35.c | 8 +++++---
hw/input/pckbd.c | 5 -----
hw/isa/lpc_ich9.c | 9 +++++++++
hw/isa/piix.c | 9 +++++++++
hw/{i386 => isa}/port92.c | 14 +-------------
hw/isa/vt82c686.c | 7 +++++++
hw/i386/Kconfig | 1 +
hw/i386/meson.build | 3 +--
hw/i386/trace-events | 4 ----
hw/isa/Kconfig | 6 ++++++
hw/isa/meson.build | 3 ++-
hw/isa/trace-events | 4 ++++
19 files changed, 104 insertions(+), 44 deletions(-)
create mode 100644 include/hw/isa/port92.h
rename hw/{i386 => isa}/port92.c (91%)
--
2.43.2
