Am 27. Februar 2024 21:54:19 UTC schrieb BALATON Zoltan <bala...@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-ayl...@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 <shen...@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.
>
>> 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. 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.
>
>>> A couple of thoughts as to why I came to this conclusion: firstly the
>>> superio chip is generally considered to be a single integrated
>>> implementation of legacy IO devices, so this feels like a natural home for
>>> the PORT92 device.
>>
>>> Secondly the value of the "has-port92" property is controlled by
>>> pcms->i8042_enabled, and this value is already passed into functions such
>>> as pc_superio_init() for example.
>>
>> Rhight. There, it also controls the presence of port 92. If we move port 92
>> into the southbridges, we have to respect this command line switch there to
>> preserve backward compatibility.
>>
>> I wonder what `-M i8042` is supposed to do. If it is for modeling a
>> stripped-down x86 system, why not use the microvm instead? How is it
>> possible to omit an essential piece of hardware needed to boot x86 systems?
>> Don't we need at least either one (i8042 or port 92)?
>
>Try git log -p 4ccd5fe22fe (found it via git blame and see what added that
>property).
Alright, the intention was to omit the PS/2 controller in favor of USB. That
doesn't mean that port 92 needs to be affected. I see an opportunity here to
reduce the scope of the i8042 option which may help with data-driven machine
creation in the future.
>
>>> I think this would also help reduce the changes required for the individual
>>> machines, however the devil is always in the details particularly when
>>> migration is involved.
>>
>> As stated above, this series is more about modeling real hardware, in the
>> hope that this will lend itself for configuration-driven machine creation.
>> It is also about identifying obstacles towards this goal. Does it make sense
>> to deprecate some machine-specific options such as i8042?
>
>Only if you want to break downsteam users of those options but maybe they
>won't be happy about that.
I don't want to break downstream users of course.
I want device models true to the original. I think that this series is a step
in this direction, hence I'd like feedback for achieving that. What's necessary
to get this series in?
Best regards,
Bernhard
>
>Regards,
>BALATON Zoltan
