From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34208) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1euPip-0004eH-1k for qemu-devel@nongnu.org; Fri, 09 Mar 2018 16:38:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1euPil-00056u-UF for qemu-devel@nongnu.org; Fri, 09 Mar 2018 16:38:39 -0500 Received: from mail-pg0-x244.google.com ([2607:f8b0:400e:c05::244]:35473) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1euPil-00055b-Lx for qemu-devel@nongnu.org; Fri, 09 Mar 2018 16:38:35 -0500 Received: by mail-pg0-x244.google.com with SMTP id l131so4048538pga.2 for ; Fri, 09 Mar 2018 13:38:35 -0800 (PST) Sender: Guenter Roeck Date: Fri, 9 Mar 2018 13:38:32 -0800 From: Guenter Roeck Message-ID: <20180309213832.GA8594@roeck-us.net> References: <1520444223-8389-1-git-send-email-linux@roeck-us.net> <20180309182030.GA22836@roeck-us.net> <201803091053.43494.wpaul@windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201803091053.43494.wpaul@windriver.com> Subject: Re: [Qemu-devel] [PATCH] fsl-imx6: Swap Ethernet interrupt defines List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bill Paul Cc: Peter Maydell , QEMU Developers , Andrey Smirnov , Chris Healy , Jason Wang , Jean-Christophe Dubois 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 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