IMX FEC model- modification in interrupts

IMX FEC model- modification in interrupts

[Olek, Adam]

[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]

Dear QEMU Team,
We have tried to up and running QNX 7.0 on QEMU 5.2.0 Sabrelite model. The QNX reach the prompt and was responsive to user command.
However, starting the network caused a QNX freeze. After debugging the problem at QNX and QEMU sites we end up with a solution which requires a slight QEMU source code modification.
It seem that the hw/net/imx_fec.c is source of the problem. To fix the issue we changed the condition in line 442 from:
if (s->regs[ENET_EIR] & s->regs[ENET_EIMR] &
     (ENET_INT_MAC | ENET_INT_TS_TIMER)) {
to:
if (s->regs[ENET_EIR] & s->regs[ENET_EIMR] & ENET_INT_TS_TIMER) {
Without this modification the PTP (Precise Time Protocol, 1588 IRQ) interrupt was generated each time any of the network interrupts occurred.
This was making QNX freeze when ifconfig has been called, because QNX was flooded by PTP interrupts that haven't occurred.
With this modification QEMU will generate PTP interrupt when it actually occurs. Just to cross check, this modification does not impact the Linux performance in any way.
Can anyone take a closer look at this condition and confirm that this modification make sense and it hasn't negative impact on anything else?
Regards,
Adam Olek
Senior Software Engineer
APTIV

[-- Attachment #2: Type: text/html, Size: 5316 bytes --]

Re: IMX FEC model- modification in interrupts

[Peter Maydell]

On Thu, 11 Mar 2021 at 09:27, Olek, Adam <adam.olek@aptiv.com> wrote:
> We have tried to up and running QNX 7.0 on QEMU 5.2.0 Sabrelite model. The QNX reach the prompt and was responsive to user command.
> However, starting the network caused a QNX freeze. After debugging the problem at QNX and QEMU sites we end up with a solution which requires a slight QEMU source code modification.
>
> It seem that the hw/net/imx_fec.c is source of the problem. To fix the issue we changed the condition in line 442 from:
>
> if (s->regs[ENET_EIR] & s->regs[ENET_EIMR] &
>      (ENET_INT_MAC | ENET_INT_TS_TIMER)) {
>
> to:
>
> if (s->regs[ENET_EIR] & s->regs[ENET_EIMR] & ENET_INT_TS_TIMER) {

> Can anyone take a closer look at this condition and confirm that this modification make sense and it hasn’t negative impact on anything else?

There is a massive comment immediately before these lines of code
which explains why it is doing what it is doing, what would
stop working, and what other functionality in QEMU needs to be
implemented in order for the hack to be removed...

thanks
-- PMM

RE: EXT SENDER - Re: IMX FEC model- modification in interrupts

[Olek, Adam]

Thank you for your answer, we understand that compatibility with all Linux versions is a priority for you.
We have small hope that this email will help other QEMU users in struggling with QNX on QEMU.

Regards,
Adam Olek

-----Original Message-----
From: Peter Maydell [mailto:peter.maydell@linaro.org] 
Sent: Thursday, March 11, 2021 8:07 PM
To: Olek, Adam <adam.olek@aptiv.com>
Cc: qemu-devel@nongnu.org
Subject: EXT SENDER - Re: IMX FEC model- modification in interrupts

On Thu, 11 Mar 2021 at 09:27, Olek, Adam <adam.olek@aptiv.com> wrote:
> We have tried to up and running QNX 7.0 on QEMU 5.2.0 Sabrelite model. The QNX reach the prompt and was responsive to user command.
> However, starting the network caused a QNX freeze. After debugging the problem at QNX and QEMU sites we end up with a solution which requires a slight QEMU source code modification.
>
> It seem that the hw/net/imx_fec.c is source of the problem. To fix the issue we changed the condition in line 442 from:
>
> if (s->regs[ENET_EIR] & s->regs[ENET_EIMR] &
>      (ENET_INT_MAC | ENET_INT_TS_TIMER)) {
>
> to:
>
> if (s->regs[ENET_EIR] & s->regs[ENET_EIMR] & ENET_INT_TS_TIMER) {

> Can anyone take a closer look at this condition and confirm that this modification make sense and it hasn’t negative impact on anything else?

There is a massive comment immediately before these lines of code which explains why it is doing what it is doing, what would stop working, and what other functionality in QEMU needs to be implemented in order for the hack to be removed...

thanks
-- PMM