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.
