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

[Guenter Roeck]

On Thu, Mar 08, 2018 at 02:51:04PM +0000, Peter Maydell wrote:
> On 8 March 2018 at 14:47, Guenter Roeck <address@hidden> wrote:
> > On 03/08/2018 02:50 AM, Peter Maydell wrote:
> >> So do the works-by-accident kernels fail on QEMU because
> >> we don't emulate some bit of the ethernet device ?
> >> Ideally we could fix that so we could boot newer kernels
> >> without breaking the old ones...
> 
> >
> > I don't know if a fix working for all versions of Linux is even possible.
> > Creating both interrupts might be an option, but would likely cause
> > other problems since some versions of Linux would handle the same
> > interrupt twice, while others expect the second interrupt
> > to be associated with the timer.
> 
> Did the older Linux kernels work on the real hardware? (I
> would guess so, but sometimes these things only get tested
> on emulation...) If so, then in theory "make QEMU work like
> the hardware" should allow all the kernels to work on QEMU.
> 
Older kernels (4.9 and earlier) register the second interrupt
on a gpio pin.

Linux 4.1, ToT qemu with this patch applied:

 38:          0  gpio-mxc   6 Level     2188000.ethernet
286:          0       GIC 151 Level     2188000.ethernet

Linux 4.1, ToT qemu without this patch:

 38:          0  gpio-mxc   6 Level     2188000.ethernet
286:         64       GIC 151 Level     2188000.ethernet

linux 4.14, ToT qemu with this patch:

 64:         64     GIC-0 150 Level     2188000.ethernet
 65:          0     GIC-0 151 Level     2188000.ethernet

linux 4.14, ToT qemu without this patch:

 64:          0     GIC-0 150 Level     2188000.ethernet
 65:         64     GIC-0 151 Level     2188000.ethernet

Presumably real hardware generates interrupts on the gpio pin.

The qemu code specifically states that it won't generate
MDIO related interrupts on gpio pins. From hw/net/imx_fec.c:

/*
 * The MII phy could raise a GPIO to the processor which in turn
 * could be handled as an interrpt by the OS.
 * For now we don't handle any GPIO/interrupt line, so the OS will
 * have to poll for the PHY status.
 */

Linux doesn't poll the phy but expects interrupts to work. I have
no idea what is supposed to happen with regular ethernet interrupts,
and if those are also mapped to a gpio pin on real hardware.

Any idea how to fix this ?

Guenter