Re: [Qemu-devel] [PATCH] fsl-imx6: Swap Ethernet interrupt defines

[Peter Maydell <peter.maydell@linaro.org>]

On 8 March 2018 at 18:28, Bill Paul <wpaul@windriver.com> wrote:
> Anyway, this means that the only reason older Linux kernels worked in QEMU
> with the broken interrupt configuration is that they also registered a handler
> on vector 151 (119). Even though QEMU could not send events via GPIO6, it was
> mistakenly sending them via vector 151, so it looked like things worked. On
> real hardware, the older kernels would have gotten their interrupts via GPIO6
> and also worked. The older kernels would _not_ work if you fix QEMU because
> now they would never get interrupts on either vector, unless you fudge things
> so that the ENET module triggers both vector 150 and the vector for GPIO6 in
> the GIC or patch them to back out the erratum 6678 workaround as later kernels
> do.

Thanks for that really useful writeup. So if I understand correctly
we have several choices here:

 (1) we could implement a model of the IOMUX block that is at least
 sufficient to support guests that configure it to route the ENET interrupt
 line to a GPIO pin. Then we could apply this patch that fixes the ENET
 line definitions. Old kernels would continue to work (for the same
 reason they worked on hardware), and new ones would work now too.
 This is in some ways the preferred option, but it's possibly a lot
 of code and we're nearly in freeze for 2.12.

 (2) we could leave everything as it is for 2.12. This would mean that
 at least we don't regress setups that used to work on older QEMU versions.
 Downside is that we wouldn't be able to run Linux v4.15+, or other
 guest OSes that don't have the bug that older Linux kernels do.
 (Presumably we'd only do this on the understanding that we were going
 to go down route (1) for 2.13.)

 (3) we could apply this patch for 2.12. Linux v4.15+ now works, as
 do other guest OSes that use the ENET interrupt. v4.1 and older Linux
 guests that used to boot in QEMU stop doing so, and 4.2-4.9 boot but
 lose the ethernet device support. Perhaps for 2.13 we might
 take route (1) to make those older guests start working again.

Do I have that right?

None of these options seems especially palatable to me, so we're
choosing the lesser evil, I think... (unless somebody wants to say
that option (1) would be 20 lines of code and here's the patch :-))
I guess in the absence of (1) that (3) is better than (2) ?

[NB: I have just sent a target-arm pull request but that doesn't mean
this patch has missed the boat for 2.12, since it's in any case
a bug fix.]

thanks
-- PMM