All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Bill Paul <wpaul@windriver.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Andrey Smirnov <andrew.smirnov@gmail.com>,
	Chris Healy <cphealy@gmail.com>, Jason Wang <jasowang@redhat.com>,
	Jean-Christophe Dubois <jcd@tribudubois.net>
Subject: Re: [Qemu-devel] [PATCH] fsl-imx6: Swap Ethernet interrupt defines
Date: Fri, 9 Mar 2018 10:20:30 -0800	[thread overview]
Message-ID: <20180309182030.GA22836@roeck-us.net> (raw)
In-Reply-To: <CAFEAcA9T=sydu47UGry2TVOa0gZF8SZLnaaQ5gqzTQmAgm2b1w@mail.gmail.com>

On Fri, Mar 09, 2018 at 05:47:16PM +0000, Peter Maydell wrote:
> 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?
> 
Pretty much.

> 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) ?
> 

I would prefer (2). This is what I decided to use in my "local"
version of qemu. Older versions of Linux can be fixed by applying one
(4.2..4.9) or two (4.1 and older) upstream patches; anyone interested
running those kernels in qemu with Ethernet working should apply those
patches (or, alternatively, provide a patch adding IOMUX support to
qemu).

Thanks,
Guenter

  reply	other threads:[~2018-03-09 18:20 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-07 17:37 [Qemu-devel] [PATCH] fsl-imx6: Swap Ethernet interrupt defines Guenter Roeck
2018-03-08 10:50 ` Peter Maydell
2018-03-08 14:47   ` Guenter Roeck
2018-03-08 14:51     ` Peter Maydell
2018-03-08 15:05       ` Guenter Roeck
2018-03-08 17:12       ` Guenter Roeck
2018-03-08 18:28         ` Bill Paul
2018-03-08 19:22           ` Guenter Roeck
2018-03-09 17:47           ` Peter Maydell
2018-03-09 18:20             ` Guenter Roeck [this message]
2018-03-09 18:48               ` Peter Maydell
2018-03-09 20:19                 ` Guenter Roeck
2018-03-09 18:53               ` Bill Paul
2018-03-09 18:57                 ` Bill Paul
2018-03-09 21:38                 ` Guenter Roeck
2018-03-09 23:03                   ` Bill Paul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180309182030.GA22836@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=andrew.smirnov@gmail.com \
    --cc=cphealy@gmail.com \
    --cc=jasowang@redhat.com \
    --cc=jcd@tribudubois.net \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=wpaul@windriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.