qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug 1815721] Re: RISC-V PLIC enable interrupt for multicore


From: RTOS Pharos
Subject: [Bug 1815721] Re: RISC-V PLIC enable interrupt for multicore
Date: Tue, 24 Mar 2020 08:14:36 -0000

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]