Re: [PATCH 2/2] via-ide: Also emulate non 100% native mode

[Mark Cave-Ayland]

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

5) Remove the PCI_INTERRUPT_LINE logic from via_ide_set_irq() and instead just 
do
qemu_set_irq() on legacy_irq[0] (in theory I guess it should be legacy_irq[n] 
but it
seems that both drives on MIPS and Pegasos both use IRQ 14).


ATB,

Mark.