On 06/03/2020 00:21, BALATON Zoltan wrote: > On Fri, 6 Mar 2020, BALATON Zoltan wrote: >> On Thu, 5 Mar 2020, Mark Cave-Ayland wrote: >>> On 04/03/2020 22:33, BALATON Zoltan wrote: >>> another possibility: PCI configuration space register 0x3d (Interrupt pin) >>> is >>> documented as having value 0 == Legacy IRQ routing which should be the >>> initial value >>> on reset, but QEMU incorrectly sets it to 1 which indicates PCI IRQ routing. >> >> The VT8231 docs say this should always read 1 but may be this is somehow set >> to 0 >> on the Pegasos2. What does that mean? Should we use this value instead of the >> feature bit to force using legacy interrupts? We'd still need a property in >> via-ide >> to set this reg or is it possible to set it from board code overriding the >> default >> after device is created? That would allow to drop patch 1. I can try this. > > This seemed like it could simplify patches a bit but it does not work. > Setting this > reg to 0 breaks Linux and MorphOS which then think the device does not have an > interrupt at all and fail as before waiting for the irq. So we still need the > feature > bit, cant use this reg to force legacy interrupts. I've spent considerable > time > testing different OSes before I've ended up with this patch series I've > submitted and > I could not find a simpler way that works with everything.
I appreciate that testing these things can take a lot of time, but what is important thing to ask here is whether these hacks are attempting to work around something in QEMU that doesn't match the hardware specification, and to me it feels that this is what is happening here. Obviously this thread has become quite long (and even I'm struggling to find previous discussions) but here is my summary below: - I don't think the patch in its current form is the right way to do this. Instead of adding a feature bit to fudge the existing IRQ routing when the existing IRQ routing is wrong, let's fix the existing IRQ routing instead. - There is no mention of "non-100%" native mode in the 8231 or 686B datasheet: this is simply a term used within the Linux patches. The controller is either in native mode, or legacy mode. It may be that guests are making use of some undefined behaviour here. - The code that uses the value of PCI_INTERRUPT_LINE in via-ide is incorrect (as your patch comment points out, some guests ignore it anyway). - There is different behaviour here between the 8231 and 686B in this area, despite having the same vendor/device id. The first thing you need to fix is the PCI_INTERRUPT_LINE part; I would start by removing the existing code and instead expose a qdev named gpio "legacy-irq" and wiring that up to your interrupt controller. Note you'd have to do the same for fulong2e, but that is reasonably trivial. ATB, Mark.