On 2/21/22 13:33, Gerd Hoffmann wrote:
Hi,
ICH6 and ICH7 IDE controllers are quite the same as far as I know. I
could change it, but then one could argue that the name ich6-ide seems
like "ich9-ide", so not sure if we can really go on this path.
I think we don't actually have ich9-ide, we only have piix3, piix4 and ahci,
the latter is used by ich9. I just said that calling this new device
ich7-ide instead of ich6-ide would make it more clear it has nothing to do
with ich9.
Well, there actually is ich9-ide in physical hardware. And it's quite
simliar for all ich6 -> ich9 (and possibly more) physical hardware.
I know, but I based it on Intel documentation and the ICH7 machine I
have from 2009. Also, according to libata in Linux, the enum of
piix_controller_ids include ich5, ich6 and ich8 (and much more, these
are more relevant in the list for this reason), and by looking into what
ich6_sata is being used for, I can see it matches the IDE controller PCI
ID on the ICH7 machine I use, so that's another reason to choose this name.
The hardware implements both ide and sata. Typically the bios setup
offers to pick ide or sata mode for the storage controller, and on boot
the chipset is configured accordingly by the firmware.
Yes, and then the BIOS configures the MAP register to indicate the setup
that it was decided by the user in the BIOS configuration.
However, setting the MAP register to zero is a valid value - it
indicates you have only SATA connectors in use (at least that's what
Linux thinks), according to the Intel ICH5 Serial ATA Controller RPM.
qemu never bothered to implement ide mode for q35/ich9. When a guest OS
is so old that it doesn't come with a sata driver there is the option to
just use the 'pc' machine type. And usually that's the better choice
anyway because these old guests tend to have problems with other q35
components too.
That's true if you care about giving emulation only for the benefits of
the guest (so you only care about supporting what the guest OS can
expect from standard IDE controller, not edge cases), but my approach is
looking at a very different goal.
So I'm wondering why you implement ich{6,7,9}-ide in the first place?
What is the use case / benefit?
I talked about it in the last patch about this topic I've sent (v1 to be
precise), but let me describe it again :)
I'm a SerenityOS developer, as you might remember or not, I've talked to
you (Gerd) in the past about SeaBIOS topics related to the OS off-list.
As I said before in this mail, I tend to test the SerenityOS kernel on
the ICH7 machine I have from 2009. That machine has 4 SATA ports and you
can connect 2 PATA devices (as one parallel cable can be used to connect
two devices at once, to one connector on the mainboard).
I've seen that the kernel struggled to use the IDE controller - the main
problem we have is long timeouts because of some problematic pattern in
our code. However, on regular QEMU PC and Q35 machines everything boots
fine. When I wrote this emulation component, I saw the same problem I
had on the bare metal machine, so it is a convenient feature for me to
debug this problem without having to use the bare metal machine - it
helps saving lots of time for me by avoiding the need to compile a
kernel, put it on the SATA harddrive and try to boot it in the rapid
compile-boot-test cycle I have here.
I thought it might be beneficial for other OS developers and hobbyists
like me to have such component. For now, it's an IDE
ICH5/6/7/9-compatible controller, supporting only PCI IDE native mode -
which means you can relocate the resources to anything you want on the
IO space, so it's a legacy-free device in the sense of PCI bus resource
management, but still a legacy device that to use it on bare metal you
need a machine from late 2000s.
Also, I do see a point in expanding this controller with more features.
For example, some ICH6 IDE controllers had AHCI mode within them, so you
could actually enable the AHCI mode and disable IDE mode if you know
what you're doing - you will probably need to assign the IDE PCI BARs
correctly first if you want IDE mode in such controller, or ignore it
and go with AHCI mode instead. Also, this emulation component is only
about PCI IDE native mode currently, but we can easily put it that you
can switch channels between compatibility mode and native mode if wanted
to. My ICH7 test machine has such controller - it allows you to switch
between the two modes, so the OS can decide what to do with the IDE
controller according to its needs.
take care,
Gerd
Best regards,
Liav
