qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] [Bug 1815721] [NEW] RISC-V PLIC enable interrupt for multicore
@ 2019-02-13  7:37 RTOS Pharos
  2020-03-24  8:14 ` [Bug 1815721] " RTOS Pharos
                   ` (3 more replies)
  0 siblings, 4 replies; 7+ messages in thread
From: RTOS Pharos @ 2019-02-13  7:37 UTC (permalink / raw)
  To: qemu-devel

Public bug reported:

Hello all,

There is a bug in Qemu related to the enabling of external interrupts
for multicores (Virt machine).

After correcting Qemu as described in #1815078
(https://bugs.launchpad.net/qemu/+bug/1815078), when we try to enable
interrupts for core 1 at address 0x0C00_2080 we don't seem to be able to
trigger an external interrupt  (e.g. UART0).

This works perfectly for core 0, but fore core 1 it does not work at
all. I assume that given bug #1815078 does not enable any external
interrupt then this feature has not been tested. I tried to look at the
qemu source code but with no luck so far.

I guess the problem is related to function parse_hart_config (in
sfive_plic.c) that initializes incorrectly the
plic->addr_config[addrid].hartid, which is later on read in
sifive_plic_update. But this is a guess.

Best regards,
Pharos team

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1815721

Title:
  RISC-V PLIC enable interrupt for multicore

Status in QEMU:
  New

Bug description:
  Hello all,

  There is a bug in Qemu related to the enabling of external interrupts
  for multicores (Virt machine).

  After correcting Qemu as described in #1815078
  (https://bugs.launchpad.net/qemu/+bug/1815078), when we try to enable
  interrupts for core 1 at address 0x0C00_2080 we don't seem to be able
  to trigger an external interrupt  (e.g. UART0).

  This works perfectly for core 0, but fore core 1 it does not work at
  all. I assume that given bug #1815078 does not enable any external
  interrupt then this feature has not been tested. I tried to look at
  the qemu source code but with no luck so far.

  I guess the problem is related to function parse_hart_config (in
  sfive_plic.c) that initializes incorrectly the
  plic->addr_config[addrid].hartid, which is later on read in
  sifive_plic_update. But this is a guess.

  Best regards,
  Pharos team

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1815721/+subscriptions

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [Bug 1815721] Re: RISC-V PLIC enable interrupt for multicore
  2019-02-13  7:37 [Qemu-devel] [Bug 1815721] [NEW] RISC-V PLIC enable interrupt for multicore RTOS Pharos
@ 2020-03-24  8:14 ` RTOS Pharos
  2020-03-24 10:35   ` Bin Meng
  2020-03-25 17:04 ` RTOS Pharos
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 7+ messages in thread
From: RTOS Pharos @ 2020-03-24  8:14 UTC (permalink / raw)
  To: qemu-devel

Hi,

After some debugging (and luck), the problem (at least in the Virt
board) was that the PLIC code inside QEMU addresses the core x 2 instead
of just the core (core=hart). That is why it worked for core 0 (0x2 = 0)
but for core 1 it has to address the PLIC memory area for core 2.

For example, the interrupt enable address for core 1 starts at offset
0x002080 (see https://github.com/riscv/riscv-plic-spec/blob/master
/riscv-plic.adoc) but we actually have to change the enable bit for core
2 (at 0x002100) to make to work for core 1.

The same is true for the priority threshold and claim complete registers
(we need to multiply the core by 2)

Either the documentation at https://github.com/riscv/riscv-plic-
spec/blob/master/riscv-plic.adoc does not have the correct memory
addresses for qemu virt board, or qemu appears to be wrong.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1815721

Title:
  RISC-V PLIC enable interrupt for multicore

Status in QEMU:
  New

Bug description:
  Hello all,

  There is a bug in Qemu related to the enabling of external interrupts
  for multicores (Virt machine).

  After correcting Qemu as described in #1815078
  (https://bugs.launchpad.net/qemu/+bug/1815078), when we try to enable
  interrupts for core 1 at address 0x0C00_2080 we don't seem to be able
  to trigger an external interrupt  (e.g. UART0).

  This works perfectly for core 0, but fore core 1 it does not work at
  all. I assume that given bug #1815078 does not enable any external
  interrupt then this feature has not been tested. I tried to look at
  the qemu source code but with no luck so far.

  I guess the problem is related to function parse_hart_config (in
  sfive_plic.c) that initializes incorrectly the
  plic->addr_config[addrid].hartid, which is later on read in
  sifive_plic_update. But this is a guess.

  Best regards,
  Pharos team

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1815721/+subscriptions


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Bug 1815721] Re: RISC-V PLIC enable interrupt for multicore
  2020-03-24  8:14 ` [Bug 1815721] " RTOS Pharos
@ 2020-03-24 10:35   ` Bin Meng
  2020-03-24 10:35     ` Bin Meng
  0 siblings, 1 reply; 7+ messages in thread
From: Bin Meng @ 2020-03-24 10:35 UTC (permalink / raw)
  To: Bug 1815721; +Cc: qemu-devel@nongnu.org Developers

On Tue, Mar 24, 2020 at 4:20 PM RTOS Pharos <1815721@bugs.launchpad.net> wrote:
>
> Hi,
>
> After some debugging (and luck), the problem (at least in the Virt
> board) was that the PLIC code inside QEMU addresses the core x 2 instead
> of just the core (core=hart). That is why it worked for core 0 (0x2 = 0)
> but for core 1 it has to address the PLIC memory area for core 2.
>
> For example, the interrupt enable address for core 1 starts at offset
> 0x002080 (see https://github.com/riscv/riscv-plic-spec/blob/master
> /riscv-plic.adoc) but we actually have to change the enable bit for core
> 2 (at 0x002100) to make to work for core 1.


https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc says:

"base + 0x002080: Enable bits for sources 0-31 on context 1"

This is context 1, not core 1.

It looks to me you were running an image built for SiFive FU540.
Please test your image against "sifive_u" machine instead.

>
> The same is true for the priority threshold and claim complete registers
> (we need to multiply the core by 2)
>
> Either the documentation at https://github.com/riscv/riscv-plic-
> spec/blob/master/riscv-plic.adoc does not have the correct memory
> addresses for qemu virt board, or qemu appears to be wrong.
>
> --

Regards,
Bin


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Bug 1815721] Re: RISC-V PLIC enable interrupt for multicore
  2020-03-24 10:35   ` Bin Meng
@ 2020-03-24 10:35     ` Bin Meng
  0 siblings, 0 replies; 7+ messages in thread
From: Bin Meng @ 2020-03-24 10:35 UTC (permalink / raw)
  To: qemu-devel

On Tue, Mar 24, 2020 at 4:20 PM RTOS Pharos <1815721@bugs.launchpad.net> wrote:
>
> Hi,
>
> After some debugging (and luck), the problem (at least in the Virt
> board) was that the PLIC code inside QEMU addresses the core x 2 instead
> of just the core (core=hart). That is why it worked for core 0 (0x2 = 0)
> but for core 1 it has to address the PLIC memory area for core 2.
>
> For example, the interrupt enable address for core 1 starts at offset
> 0x002080 (see https://github.com/riscv/riscv-plic-spec/blob/master
> /riscv-plic.adoc) but we actually have to change the enable bit for core
> 2 (at 0x002100) to make to work for core 1.


https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc says:

"base + 0x002080: Enable bits for sources 0-31 on context 1"

This is context 1, not core 1.

It looks to me you were running an image built for SiFive FU540.
Please test your image against "sifive_u" machine instead.

>
> The same is true for the priority threshold and claim complete registers
> (we need to multiply the core by 2)
>
> Either the documentation at https://github.com/riscv/riscv-plic-
> spec/blob/master/riscv-plic.adoc does not have the correct memory
> addresses for qemu virt board, or qemu appears to be wrong.
>
> --

Regards,
Bin

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1815721

Title:
  RISC-V PLIC enable interrupt for multicore

Status in QEMU:
  New

Bug description:
  Hello all,

  There is a bug in Qemu related to the enabling of external interrupts
  for multicores (Virt machine).

  After correcting Qemu as described in #1815078
  (https://bugs.launchpad.net/qemu/+bug/1815078), when we try to enable
  interrupts for core 1 at address 0x0C00_2080 we don't seem to be able
  to trigger an external interrupt  (e.g. UART0).

  This works perfectly for core 0, but fore core 1 it does not work at
  all. I assume that given bug #1815078 does not enable any external
  interrupt then this feature has not been tested. I tried to look at
  the qemu source code but with no luck so far.

  I guess the problem is related to function parse_hart_config (in
  sfive_plic.c) that initializes incorrectly the
  plic->addr_config[addrid].hartid, which is later on read in
  sifive_plic_update. But this is a guess.

  Best regards,
  Pharos team

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1815721/+subscriptions


^ permalink raw reply	[flat|nested] 7+ messages in thread

* [Bug 1815721] Re: RISC-V PLIC enable interrupt for multicore
  2019-02-13  7:37 [Qemu-devel] [Bug 1815721] [NEW] RISC-V PLIC enable interrupt for multicore RTOS Pharos
  2020-03-24  8:14 ` [Bug 1815721] " RTOS Pharos
@ 2020-03-25 17:04 ` RTOS Pharos
  2020-09-28  7:15 ` Teodori Serge
  2020-11-19 20:24 ` Alistair Francis
  3 siblings, 0 replies; 7+ messages in thread
From: RTOS Pharos @ 2020-03-25 17:04 UTC (permalink / raw)
  To: qemu-devel

Thank you for the explanation. I actually built it for "Virt" machine.
I'll try the "sifive_u" when I can.

But I guess your explanation is correct so this bug could be closed from
my part.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1815721

Title:
  RISC-V PLIC enable interrupt for multicore

Status in QEMU:
  New

Bug description:
  Hello all,

  There is a bug in Qemu related to the enabling of external interrupts
  for multicores (Virt machine).

  After correcting Qemu as described in #1815078
  (https://bugs.launchpad.net/qemu/+bug/1815078), when we try to enable
  interrupts for core 1 at address 0x0C00_2080 we don't seem to be able
  to trigger an external interrupt  (e.g. UART0).

  This works perfectly for core 0, but fore core 1 it does not work at
  all. I assume that given bug #1815078 does not enable any external
  interrupt then this feature has not been tested. I tried to look at
  the qemu source code but with no luck so far.

  I guess the problem is related to function parse_hart_config (in
  sfive_plic.c) that initializes incorrectly the
  plic->addr_config[addrid].hartid, which is later on read in
  sifive_plic_update. But this is a guess.

  Best regards,
  Pharos team

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1815721/+subscriptions


^ permalink raw reply	[flat|nested] 7+ messages in thread

* [Bug 1815721] Re: RISC-V PLIC enable interrupt for multicore
  2019-02-13  7:37 [Qemu-devel] [Bug 1815721] [NEW] RISC-V PLIC enable interrupt for multicore RTOS Pharos
  2020-03-24  8:14 ` [Bug 1815721] " RTOS Pharos
  2020-03-25 17:04 ` RTOS Pharos
@ 2020-09-28  7:15 ` Teodori Serge
  2020-11-19 20:24 ` Alistair Francis
  3 siblings, 0 replies; 7+ messages in thread
From: Teodori Serge @ 2020-09-28  7:15 UTC (permalink / raw)
  To: qemu-devel

Hello as far as I can tell, there is a major problem with PLIC
implementation. When decompiling DTB on virt board with X harts, I see
that hartid 0 has MEI and SEI, hartid 1 has MEI and SEI, etc... But when
configuring context 1 (hartid 0 SEI) no interrupt is generated, but
context 0, 2, 4 etc... work. So for me the problem is within PLIC or
RISC-V implementation... If anyone wants to correct it, I can help. Best
regards. Serge Teodori

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1815721

Title:
  RISC-V PLIC enable interrupt for multicore

Status in QEMU:
  New

Bug description:
  Hello all,

  There is a bug in Qemu related to the enabling of external interrupts
  for multicores (Virt machine).

  After correcting Qemu as described in #1815078
  (https://bugs.launchpad.net/qemu/+bug/1815078), when we try to enable
  interrupts for core 1 at address 0x0C00_2080 we don't seem to be able
  to trigger an external interrupt  (e.g. UART0).

  This works perfectly for core 0, but fore core 1 it does not work at
  all. I assume that given bug #1815078 does not enable any external
  interrupt then this feature has not been tested. I tried to look at
  the qemu source code but with no luck so far.

  I guess the problem is related to function parse_hart_config (in
  sfive_plic.c) that initializes incorrectly the
  plic->addr_config[addrid].hartid, which is later on read in
  sifive_plic_update. But this is a guess.

  Best regards,
  Pharos team

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1815721/+subscriptions


^ permalink raw reply	[flat|nested] 7+ messages in thread

* [Bug 1815721] Re: RISC-V PLIC enable interrupt for multicore
  2019-02-13  7:37 [Qemu-devel] [Bug 1815721] [NEW] RISC-V PLIC enable interrupt for multicore RTOS Pharos
                   ` (2 preceding siblings ...)
  2020-09-28  7:15 ` Teodori Serge
@ 2020-11-19 20:24 ` Alistair Francis
  3 siblings, 0 replies; 7+ messages in thread
From: Alistair Francis @ 2020-11-19 20:24 UTC (permalink / raw)
  To: qemu-devel

I'm going to close this bug as it seems like the issue that RTOS Pharos
raised is not an issue.

@Teodori Serge please open a new issue if you have a bug. Make sure to
include as much detail as possible and steps to reproduce it.

** Changed in: qemu
       Status: New => Invalid

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1815721

Title:
  RISC-V PLIC enable interrupt for multicore

Status in QEMU:
  Invalid

Bug description:
  Hello all,

  There is a bug in Qemu related to the enabling of external interrupts
  for multicores (Virt machine).

  After correcting Qemu as described in #1815078
  (https://bugs.launchpad.net/qemu/+bug/1815078), when we try to enable
  interrupts for core 1 at address 0x0C00_2080 we don't seem to be able
  to trigger an external interrupt  (e.g. UART0).

  This works perfectly for core 0, but fore core 1 it does not work at
  all. I assume that given bug #1815078 does not enable any external
  interrupt then this feature has not been tested. I tried to look at
  the qemu source code but with no luck so far.

  I guess the problem is related to function parse_hart_config (in
  sfive_plic.c) that initializes incorrectly the
  plic->addr_config[addrid].hartid, which is later on read in
  sifive_plic_update. But this is a guess.

  Best regards,
  Pharos team

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1815721/+subscriptions


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2020-11-19 20:49 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-13  7:37 [Qemu-devel] [Bug 1815721] [NEW] RISC-V PLIC enable interrupt for multicore RTOS Pharos
2020-03-24  8:14 ` [Bug 1815721] " RTOS Pharos
2020-03-24 10:35   ` Bin Meng
2020-03-24 10:35     ` Bin Meng
2020-03-25 17:04 ` RTOS Pharos
2020-09-28  7:15 ` Teodori Serge
2020-11-19 20:24 ` Alistair Francis

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).