[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] fsl-imx6: Swap Ethernet interrupt defines
From: |
Guenter Roeck |
Subject: |
Re: [Qemu-devel] [PATCH] fsl-imx6: Swap Ethernet interrupt defines |
Date: |
Fri, 9 Mar 2018 13:38:32 -0800 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Fri, Mar 09, 2018 at 10:53:43AM -0800, Bill Paul wrote:
> Of all the gin joints in all the towns in all the world, Guenter Roeck had to
> walk into mine at 10:20 on Friday 09 March 2018 and say:
>
> > On Fri, Mar 09, 2018 at 05:47:16PM +0000, Peter Maydell wrote:
> > > On 8 March 2018 at 18:28, Bill Paul <address@hidden> 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?
> >
> > Pretty much.
>
> There may be a 4th option.
>
> Since older kernels work because they were looking at vector 151, you could
> patch the imx_fec.c module so that when it signals an event for vector 150,
> it
> also signals vector 151 too. This would keep newer versions of QEMU "bug-
> compatible" with older versions while also fixing support for newer Linux
> kernels and other guests (e.g. VxWorks) that follow the hardware spec
> correctly.
>
> I think this would require only a small modification to this function:
>
> static void imx_eth_update(IMXFECState *s)
> {
> if (s->regs[ENET_EIR] & s->regs[ENET_EIMR] & ENET_INT_TS_TIMER) {
> qemu_set_irq(s->irq[1], 1);
> } else {
> qemu_set_irq(s->irq[1], 0);
> }
>
> if (s->regs[ENET_EIR] & s->regs[ENET_EIMR] & ENET_INT_MAC) {
> qemu_set_irq(s->irq[0], 1);
> } else {
> qemu_set_irq(s->irq[0], 0);
> }
> }
>
> (For ENET_INT_MAC events, just signal both s->irq[0] and s->irq[1]).
>
Now this is an excellent idea.
> This of course means signaling spurious events on vector 151, but you're
> doing
> that now anyway. :)
>
Actually, it doesn't. It looks like the first interrupt is handled, resetting
the interrupt status, and the second interrupt is never even executed. I tested
this with all kernel releases back to v3.16.
I'll send out patch v2 with this change and let Peter decide which version to
apply.
Thanks,
Guenter
- Re: [Qemu-devel] [PATCH] fsl-imx6: Swap Ethernet interrupt defines, (continued)
- Re: [Qemu-devel] [PATCH] fsl-imx6: Swap Ethernet interrupt defines, Guenter Roeck, 2018/03/08
- Re: [Qemu-devel] [PATCH] fsl-imx6: Swap Ethernet interrupt defines, Guenter Roeck, 2018/03/08
- Re: [Qemu-devel] [PATCH] fsl-imx6: Swap Ethernet interrupt defines, Bill Paul, 2018/03/08
- Re: [Qemu-devel] [PATCH] fsl-imx6: Swap Ethernet interrupt defines, Guenter Roeck, 2018/03/08
- Re: [Qemu-devel] [PATCH] fsl-imx6: Swap Ethernet interrupt defines, Peter Maydell, 2018/03/09
- Re: [Qemu-devel] [PATCH] fsl-imx6: Swap Ethernet interrupt defines, Guenter Roeck, 2018/03/09
- Re: [Qemu-devel] [PATCH] fsl-imx6: Swap Ethernet interrupt defines, Peter Maydell, 2018/03/09
- Re: [Qemu-devel] [PATCH] fsl-imx6: Swap Ethernet interrupt defines, Guenter Roeck, 2018/03/09
- Re: [Qemu-devel] [PATCH] fsl-imx6: Swap Ethernet interrupt defines, Bill Paul, 2018/03/09
- Re: [Qemu-devel] [PATCH] fsl-imx6: Swap Ethernet interrupt defines, Bill Paul, 2018/03/09
- Re: [Qemu-devel] [PATCH] fsl-imx6: Swap Ethernet interrupt defines,
Guenter Roeck <=
- Re: [Qemu-devel] [PATCH] fsl-imx6: Swap Ethernet interrupt defines, Bill Paul, 2018/03/09