On 06/03/2020 12:06, BALATON Zoltan wrote:
On Fri, 6 Mar 2020, Mark Cave-Ayland wrote:
On 05/03/2020 23:35, BALATON Zoltan wrote:
On real hardware this may be true but in QEMU how would it otherwise raise the
correct interrupt line the guest expects? This probably does not matter for
pegasos2
but I think is needed for 100% native mode used with the fulong2e so it gets
the IRQ
it expects.
That's easy - remember that both the PCI and IRQ interrupts are separate pins
on the
chip, so all that needs to be done is expose the legacy IRQ via qdev and use
that to
wire it up to your interrupt controller.
This "chip" is part of an integrated southbridge/superio/everything chip the
also
includes the two PICs and how they are internally connected is not known so we
would
be guessing here anyway. I don't see a need to make it more complicated than it
is
now by modeling internal pins but how would I wire up gpio to the i8259 model
and
where should I connect the PCI irq?
For now I would say not to worry about the PCI IRQ: the reason for discussing
this
before was because we believed that if the controller was in native mode it
must be
using the IRQ in PCI_INTERRUPT_LINE. But from yesterday's read of the
specification
we know that PCI_INTERRUPT_LINE is never used by the device itself, and so
given that
the existing via-ide device doesn't currently attempt to use the PCI IRQ in
via_ide_set_irq() then we should be good.
If someone had a machine somewhere that did use the PCI IRQ then it would need
investigation, but since there isn't then I don't see any need to do this now.
Okay so this is interesting: I've been switching between the VT8231 and the
VT82C686B
datasheets, and there is a difference here. You are correct in what you say
above in
that the 8231 docs specify that this is set to 1, but on the 686B this is
clearly not
the case.
The 82C686B says this reg can be 0 or 1, where 0 is legacy interrupt routing
and 1 is
native mode. Given that we only model native mode of the chip it does not make
sense
to set it to anything else than 1 and setting it to 0 confuses MorphOS and
Linux on
pegasos2 while setting it to 1 works with everything I've tried both on
pegasos2 and
fulong2e even if that may not completely match how it's implemented in hardware.
What is rather unusual here is that both the 8231 and 686B have exactly the same
device and vendor ids, so I'm not sure how you'd distinguish between them?
Guests distinguish by looking at the parent device (function 0) which is the
chip
this IDE device is part of (on function 1).
Okay thanks, that's useful to know.
I've done a quick grep of the source tree and AFAICT the only IDE controller
that
tries to use the PCI_INTERRUPT_LINE register is via-ide, which means this
should be
fairly easy. In short:
1) Add qemu_irq legacy_irqs[2] into PCIIDEState
(You could argue that it should belong in a separate VIAIDEState, however quite
a few
of the BMDMA controllers in QEMU don't have their own device state and just use
PCIIDEState. And whilst via-ide is the only one that currently needs support for
legacy IRQs, I think it's good to put it there in case other controllers need
it in
future)
2) Add via_ide_initfn() to hw/ide/via.c and add qdev_init_gpio_out_named() with
a
name of "legacy-irq" to it
3) Inline via_ide_init() into hw/mips/mips_fulong2e.c, changing
pci_create_simple()
to pci_create() because the device shouldn't be realised immediately
4) In vt82c686b_southbridge_init use qdev_connect_gpio_out_named() to connect
legacy_irq[0] to 8259 IRQ 14 and legacy_irq[1] to 8259 IRQ 15, and then realise
the
device