On Tue, 27 Feb 2024, Bernhard Beschow wrote:
Am 27. Februar 2024 21:54:19 UTC schrieb BALATON Zoltan <balaton@eik.bme.hu>:
On Tue, 27 Feb 2024, Bernhard Beschow wrote:
Am 21. Februar 2024 11:53:21 UTC schrieb Mark Cave-Ayland
<mark.cave-ayland@ilande.co.uk>:
On 18/02/2024 13:16, Bernhard Beschow wrote:
Port 92 is an integral part of the PIIX and ICH south bridges, so instantiate it
there. The isapc machine now needs to instantiate it explicitly, analoguous to
the RTC.
Note that due to migration compatibility, port92 is optional in the south
bridges. It is always instantiated the isapc machine for simplicity.
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
---
include/hw/i386/pc.h | 2 +-
include/hw/southbridge/ich9.h | 4 ++++
include/hw/southbridge/piix.h | 3 +++
hw/i386/pc.c | 18 ++++++++++++------
hw/i386/pc_piix.c | 9 +++++++--
hw/i386/pc_q35.c | 8 +++++---
hw/isa/lpc_ich9.c | 9 +++++++++
hw/isa/piix.c | 9 +++++++++
hw/isa/Kconfig | 2 ++
9 files changed, 52 insertions(+), 12 deletions(-)
I had a look at this (and did a bit of revision around 8042 and A20), and I am
starting to wonder if the PORT92 device isn't something that belongs to the
southbridge, but more specifically to the superio chip?
If there is agreement to model real hardware in QEMU, then I think that
I think there's no such agreement and QEMU is more lax about it both for
historical reasons and to simplify machine models. Indeed, QEMU sometimes
models non-existing machines (e.g. the mac99 or virt boards) that don't
correspond to real hardware but allow guest OSes to boot. Even when modelllng
real hardware it's ofren modelled just enough for guests to work and unused
details are omitted for simplicity. It is recommended to follow what real
hardware does when modelling real hardware but not always required. Although it
might help both with verifying a device model and to compose machines with
these models to try to follow the real hardware.
Composing real machines and verifying device models is exactly what I'm after.
I'm aware that QEMU provides virt machines such as the microvm, and from the
context I didn't refer to these.
Even without pure virt machines currently a lot of QEMU machines don't exactly
model real hardware. They may roughly follow real hardware but not exactly such
as mac99 is a non-existent Mac and the pc machines also use some parts that
don't exist in real life such as PIIX4-PIIX3 hybrid you've been working on
resolving. Some of these however are restricted by backward compatibilty
requirements. But you probably aware of all of that but this means the argument
that real hardware should be followed is not enough. At least it should not
break backward compatibility too much and that's more important than exactly
modelling real machine. Also having a simple model may be more important than
modeling every detail even when not used just to follow real hardware.
port 92 belongs into any device model where the hardware has one. All our
PC-like southbridges (PIIX, ICH, VIA) have port 92. Many FDC37xxxx including
the FDC37M81x as used in the Malta board have one, too -- where it must first
be enabled.
So port92 is not a real hardware but a QEMU abstraction or model of some
functionality found in some machines. Real chips probably implement this in
different ways so we could either model this in these chips independently the
same way as real hardware does or use the abstracted model anywhere in our
machine model. Since this does not exist in real hardware as this abstract
model it also does not belong anywhere so we are free to put it where it's most
convenient or simple to do.
As mentioned already, port 92 is an integral part of PIIX, ICH, and VIA
southbridges.
Mark argued that more specifically it's part of the superio within those
couthbridges. That makes sense, considering this port92 is related to
functionality that was in the keyboard contorller before which is part of the
superio. I don't know PC hardware too well but reading about this fast gate A20
feature looks like original PC and XT had only a 1 MB address space but
addresses above 1 MB wrapped to 0 and some software depended on that. Then AT
added more memory but then it needed a way to control if addresses above 1 MB
would wrap or access high memory. This was done with some free part of the
keyboard controller but that was too slow so an alternative fast way was added
with this port92 device. But then the old keyboard controller and this port92
stuff are interacting so may need to consider both. Apart from that all of this
is not relevant to other machines that don't use this functionality.
QEMU decided to model it as a separate QOM object that is now instantiated by
the machines that use it. This is not real hardware but a QEMU implementation
detail. What's wrong with that? It seems you just want to simplify the pc
machine creation and push this object that does not correspond to some real
hardware somewhere else. But this belongs nowhere as it does not model a real
hardware.
That's why I want to move it there. My goal is to create different PC machines
in a data-driven manner which model real boards. I want to see how low-level
guests interact with the hardware, including e.g. how they set up the memory
map.
Then I think the port92 as a QOM object should be gone completely and
implemented separately in south bridges beacause in real machine there's no
such port 92 thing, only a south briege so if you need to create port92 in a
data driver machine description then that's not modeling real hardware but
reflects QEMU implementation of it. However the QOM object could be retained