On 06/03/2023 22:14, BALATON Zoltan wrote:
Can you explain a bit more about how the PCI interrupt lines are connected to both
the MV64361 and VT8231? The reason for asking is that I see a similar pattern in
the bonito board, but there I can't see how those lines would be used because they
can also raise a CPU interrupt, yet it is a different one compared to the 8259.
Given that we know from Bernhard's tests that the fuloong2e board works with
pci_bus_irqs() included in via_isa_realize() which overwrites the bonito
equivalent, I'm wondering if the mv_pirq array is actually needed at all and
Also I'd be cautious of tests on fuloong2e unless it was done with binary known to
work on real machine as we have found before that those binaries for the real machine
expect IDE to use IRQ 14/15 like pegasos2 guests but the e.g. the default config in
Linux would also work with native IRQs as documented in the datasheet but that's
apparently not how it really works on real hardware (proven by binaries written for
and tested on real hardware did not work with the model which followed the datasheet)
so we had to change that later to match hardware. You may remember this, it was found
around the time when we tested via-ide with different guests and some worked some
didn't with the native mode IRQs. This suggests that datasheets and tests with code
not verified to work on real hardware is unreliable (so are PCI standards that the
VIA chip apparently does not follow). So I'd only trust guests that were running on
the real machine.
This may have been true when these discussions occurred a couple of years ago, but
things are different now. I'm now confident that there is no such thing as a "half
native" mode, and in fact the confusing behaviour being exhibited was because the
code was trying to work around the fact that the VIA device was missing PCI IRQ routing.
Can you provide details of the kernel, initrd and rootfs that you use to test the
fuloong2e board?
ATB,
Mark.
