All of lore.kernel.org
 help / color / mirror / Atom feed
* [Bug 1886076] [NEW] risc-v pmp implementation error
@ 2020-07-02 17:14 Nicolas Royer
  2020-07-09 11:32 ` [Bug 1886076] " Laurent Vivier
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: Nicolas Royer @ 2020-07-02 17:14 UTC (permalink / raw)
  To: qemu-devel

Public bug reported:

QEMU Commit fc1bff958998910ec8d25db86cd2f53ff125f7ab


RISC-V PMP implementation is not correct on QEMU.

When an access is granted there is no more PMP check on the 4KB memory range of the accessed location.
A cache flush is needed in order to force a PMP check on next access to this 4KB memory range.
A correct implementation would be to grant access to the maximum allowed area around the accessed location within the 4KB memory range.

For instance, if PMP is configured to block all accesses from 0x80003000 to 0x800037FF and from 0x80003C00 to 0x80003FFF:
1st case:
    1) A read access is done @0x80003900 --> access OK as expected
    2) Then a read access is done @0x80003400 --> access OK while it must be blocked!
2nd case:
    1) A read access is done @0x80003900 --> access OK as expected
    2) Cache is flushed (__asm__ __volatile__ ("sfence.vma" : : : "memory");)  
    3) A read access is done @0x80003400 --> access blocked as expected

Analysis:
    After the 1st read @0x80003900 QEMU add the memory range 0x80003000 to 0x80003FFF into a TLB entry.
    Then no more PMP check is done from 0x80003000 to 0x80003FFF until the TLB is flushed.
What should be done:
    Only the range 0x80003800 to 0x80003BFF should be added to the TLB entry.

The 4KB range is the default size of a TLB page on QEMU for RISCV.
The minimum size that can be set is 64Bytes. However the PMP granularity can be as low as 4Bytes.

I tested a quick fix and PMP is working as expected.
The quick fix consist in replacing this line:
tlb_set_page(cs, address & TARGET_PAGE_MASK, pa & TARGET_PAGE_MASK, prot, mmu_idx, TARGET_PAGE_SIZE);
By this one in target/riscv/cpu_helper.c:
tlb_set_page(cs, address & ~0x3, pa & ~0x3, prot, mmu_idx, size);

This quick fix has to be optimized in order to consume less HW
resources, as explained at the beginning.

** Affects: qemu
     Importance: Undecided
         Status: New


** Tags: risc-v

** Patch added: "0001-target-riscv-Set-TLB-entry-according-to-PMP-granular.patch"
   https://bugs.launchpad.net/bugs/1886076/+attachment/5389124/+files/0001-target-riscv-Set-TLB-entry-according-to-PMP-granular.patch

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

Title:
  risc-v pmp implementation error

Status in QEMU:
  New

Bug description:
  QEMU Commit fc1bff958998910ec8d25db86cd2f53ff125f7ab

  
  RISC-V PMP implementation is not correct on QEMU.

  When an access is granted there is no more PMP check on the 4KB memory range of the accessed location.
  A cache flush is needed in order to force a PMP check on next access to this 4KB memory range.
  A correct implementation would be to grant access to the maximum allowed area around the accessed location within the 4KB memory range.

  For instance, if PMP is configured to block all accesses from 0x80003000 to 0x800037FF and from 0x80003C00 to 0x80003FFF:
  1st case:
      1) A read access is done @0x80003900 --> access OK as expected
      2) Then a read access is done @0x80003400 --> access OK while it must be blocked!
  2nd case:
      1) A read access is done @0x80003900 --> access OK as expected
      2) Cache is flushed (__asm__ __volatile__ ("sfence.vma" : : : "memory");)  
      3) A read access is done @0x80003400 --> access blocked as expected

  Analysis:
      After the 1st read @0x80003900 QEMU add the memory range 0x80003000 to 0x80003FFF into a TLB entry.
      Then no more PMP check is done from 0x80003000 to 0x80003FFF until the TLB is flushed.
  What should be done:
      Only the range 0x80003800 to 0x80003BFF should be added to the TLB entry.

  The 4KB range is the default size of a TLB page on QEMU for RISCV.
  The minimum size that can be set is 64Bytes. However the PMP granularity can be as low as 4Bytes.

  I tested a quick fix and PMP is working as expected.
  The quick fix consist in replacing this line:
  tlb_set_page(cs, address & TARGET_PAGE_MASK, pa & TARGET_PAGE_MASK, prot, mmu_idx, TARGET_PAGE_SIZE);
  By this one in target/riscv/cpu_helper.c:
  tlb_set_page(cs, address & ~0x3, pa & ~0x3, prot, mmu_idx, size);

  This quick fix has to be optimized in order to consume less HW
  resources, as explained at the beginning.

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


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

* [Bug 1886076] Re: risc-v pmp implementation error
  2020-07-02 17:14 [Bug 1886076] [NEW] risc-v pmp implementation error Nicolas Royer
@ 2020-07-09 11:32 ` Laurent Vivier
  2020-08-13 22:30 ` Alistair Francis
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: Laurent Vivier @ 2020-07-09 11:32 UTC (permalink / raw)
  To: qemu-devel

Nicolas,

to be reviewed your patch must be sent to qemu-devel@nongnu.org

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

Title:
  risc-v pmp implementation error

Status in QEMU:
  New

Bug description:
  QEMU Commit fc1bff958998910ec8d25db86cd2f53ff125f7ab

  
  RISC-V PMP implementation is not correct on QEMU.

  When an access is granted there is no more PMP check on the 4KB memory range of the accessed location.
  A cache flush is needed in order to force a PMP check on next access to this 4KB memory range.
  A correct implementation would be to grant access to the maximum allowed area around the accessed location within the 4KB memory range.

  For instance, if PMP is configured to block all accesses from 0x80003000 to 0x800037FF and from 0x80003C00 to 0x80003FFF:
  1st case:
      1) A read access is done @0x80003900 --> access OK as expected
      2) Then a read access is done @0x80003400 --> access OK while it must be blocked!
  2nd case:
      1) A read access is done @0x80003900 --> access OK as expected
      2) Cache is flushed (__asm__ __volatile__ ("sfence.vma" : : : "memory");)  
      3) A read access is done @0x80003400 --> access blocked as expected

  Analysis:
      After the 1st read @0x80003900 QEMU add the memory range 0x80003000 to 0x80003FFF into a TLB entry.
      Then no more PMP check is done from 0x80003000 to 0x80003FFF until the TLB is flushed.
  What should be done:
      Only the range 0x80003800 to 0x80003BFF should be added to the TLB entry.

  The 4KB range is the default size of a TLB page on QEMU for RISCV.
  The minimum size that can be set is 64Bytes. However the PMP granularity can be as low as 4Bytes.

  I tested a quick fix and PMP is working as expected.
  The quick fix consist in replacing this line:
  tlb_set_page(cs, address & TARGET_PAGE_MASK, pa & TARGET_PAGE_MASK, prot, mmu_idx, TARGET_PAGE_SIZE);
  By this one in target/riscv/cpu_helper.c:
  tlb_set_page(cs, address & ~0x3, pa & ~0x3, prot, mmu_idx, size);

  This quick fix has to be optimized in order to consume less HW
  resources, as explained at the beginning.

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


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

* [Bug 1886076] Re: risc-v pmp implementation error
  2020-07-02 17:14 [Bug 1886076] [NEW] risc-v pmp implementation error Nicolas Royer
  2020-07-09 11:32 ` [Bug 1886076] " Laurent Vivier
@ 2020-08-13 22:30 ` Alistair Francis
  2020-08-13 22:31 ` Alistair Francis
  2021-04-30  9:13 ` Thomas Huth
  3 siblings, 0 replies; 5+ messages in thread
From: Alistair Francis @ 2020-08-13 22:30 UTC (permalink / raw)
  To: qemu-devel

This should be fixed once the current RISC-V branch is merged into
master.

You can see the patch that fixes this here:
https://patchew.org/QEMU/20200812223045.96803-1-alistair.francis@wdc.com/20200812223045.96803-18-alistair.francis@wdc.com/

** Changed in: qemu
     Assignee: (unassigned) => Alistair Francis (alistair2323)

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

Title:
  risc-v pmp implementation error

Status in QEMU:
  Fix Committed

Bug description:
  QEMU Commit fc1bff958998910ec8d25db86cd2f53ff125f7ab

  
  RISC-V PMP implementation is not correct on QEMU.

  When an access is granted there is no more PMP check on the 4KB memory range of the accessed location.
  A cache flush is needed in order to force a PMP check on next access to this 4KB memory range.
  A correct implementation would be to grant access to the maximum allowed area around the accessed location within the 4KB memory range.

  For instance, if PMP is configured to block all accesses from 0x80003000 to 0x800037FF and from 0x80003C00 to 0x80003FFF:
  1st case:
      1) A read access is done @0x80003900 --> access OK as expected
      2) Then a read access is done @0x80003400 --> access OK while it must be blocked!
  2nd case:
      1) A read access is done @0x80003900 --> access OK as expected
      2) Cache is flushed (__asm__ __volatile__ ("sfence.vma" : : : "memory");)  
      3) A read access is done @0x80003400 --> access blocked as expected

  Analysis:
      After the 1st read @0x80003900 QEMU add the memory range 0x80003000 to 0x80003FFF into a TLB entry.
      Then no more PMP check is done from 0x80003000 to 0x80003FFF until the TLB is flushed.
  What should be done:
      Only the range 0x80003800 to 0x80003BFF should be added to the TLB entry.

  The 4KB range is the default size of a TLB page on QEMU for RISCV.
  The minimum size that can be set is 64Bytes. However the PMP granularity can be as low as 4Bytes.

  I tested a quick fix and PMP is working as expected.
  The quick fix consist in replacing this line:
  tlb_set_page(cs, address & TARGET_PAGE_MASK, pa & TARGET_PAGE_MASK, prot, mmu_idx, TARGET_PAGE_SIZE);
  By this one in target/riscv/cpu_helper.c:
  tlb_set_page(cs, address & ~0x3, pa & ~0x3, prot, mmu_idx, size);

  This quick fix has to be optimized in order to consume less HW
  resources, as explained at the beginning.

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


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

* [Bug 1886076] Re: risc-v pmp implementation error
  2020-07-02 17:14 [Bug 1886076] [NEW] risc-v pmp implementation error Nicolas Royer
  2020-07-09 11:32 ` [Bug 1886076] " Laurent Vivier
  2020-08-13 22:30 ` Alistair Francis
@ 2020-08-13 22:31 ` Alistair Francis
  2021-04-30  9:13 ` Thomas Huth
  3 siblings, 0 replies; 5+ messages in thread
From: Alistair Francis @ 2020-08-13 22:31 UTC (permalink / raw)
  To: qemu-devel

I'm marking this as fix committed, although the fix isn't yet in master
it's in the RISC-V tree and will be in master soon.

** Changed in: qemu
       Status: New => Fix Committed

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

Title:
  risc-v pmp implementation error

Status in QEMU:
  Fix Committed

Bug description:
  QEMU Commit fc1bff958998910ec8d25db86cd2f53ff125f7ab

  
  RISC-V PMP implementation is not correct on QEMU.

  When an access is granted there is no more PMP check on the 4KB memory range of the accessed location.
  A cache flush is needed in order to force a PMP check on next access to this 4KB memory range.
  A correct implementation would be to grant access to the maximum allowed area around the accessed location within the 4KB memory range.

  For instance, if PMP is configured to block all accesses from 0x80003000 to 0x800037FF and from 0x80003C00 to 0x80003FFF:
  1st case:
      1) A read access is done @0x80003900 --> access OK as expected
      2) Then a read access is done @0x80003400 --> access OK while it must be blocked!
  2nd case:
      1) A read access is done @0x80003900 --> access OK as expected
      2) Cache is flushed (__asm__ __volatile__ ("sfence.vma" : : : "memory");)  
      3) A read access is done @0x80003400 --> access blocked as expected

  Analysis:
      After the 1st read @0x80003900 QEMU add the memory range 0x80003000 to 0x80003FFF into a TLB entry.
      Then no more PMP check is done from 0x80003000 to 0x80003FFF until the TLB is flushed.
  What should be done:
      Only the range 0x80003800 to 0x80003BFF should be added to the TLB entry.

  The 4KB range is the default size of a TLB page on QEMU for RISCV.
  The minimum size that can be set is 64Bytes. However the PMP granularity can be as low as 4Bytes.

  I tested a quick fix and PMP is working as expected.
  The quick fix consist in replacing this line:
  tlb_set_page(cs, address & TARGET_PAGE_MASK, pa & TARGET_PAGE_MASK, prot, mmu_idx, TARGET_PAGE_SIZE);
  By this one in target/riscv/cpu_helper.c:
  tlb_set_page(cs, address & ~0x3, pa & ~0x3, prot, mmu_idx, size);

  This quick fix has to be optimized in order to consume less HW
  resources, as explained at the beginning.

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


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

* [Bug 1886076] Re: risc-v pmp implementation error
  2020-07-02 17:14 [Bug 1886076] [NEW] risc-v pmp implementation error Nicolas Royer
                   ` (2 preceding siblings ...)
  2020-08-13 22:31 ` Alistair Francis
@ 2021-04-30  9:13 ` Thomas Huth
  3 siblings, 0 replies; 5+ messages in thread
From: Thomas Huth @ 2021-04-30  9:13 UTC (permalink / raw)
  To: qemu-devel

Fix has been included here:
https://gitlab.com/qemu-project/qemu/-/commit/af3fc195e3c8e98b

** Changed in: qemu
       Status: Fix Committed => Fix Released

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

Title:
  risc-v pmp implementation error

Status in QEMU:
  Fix Released

Bug description:
  QEMU Commit fc1bff958998910ec8d25db86cd2f53ff125f7ab

  
  RISC-V PMP implementation is not correct on QEMU.

  When an access is granted there is no more PMP check on the 4KB memory range of the accessed location.
  A cache flush is needed in order to force a PMP check on next access to this 4KB memory range.
  A correct implementation would be to grant access to the maximum allowed area around the accessed location within the 4KB memory range.

  For instance, if PMP is configured to block all accesses from 0x80003000 to 0x800037FF and from 0x80003C00 to 0x80003FFF:
  1st case:
      1) A read access is done @0x80003900 --> access OK as expected
      2) Then a read access is done @0x80003400 --> access OK while it must be blocked!
  2nd case:
      1) A read access is done @0x80003900 --> access OK as expected
      2) Cache is flushed (__asm__ __volatile__ ("sfence.vma" : : : "memory");)  
      3) A read access is done @0x80003400 --> access blocked as expected

  Analysis:
      After the 1st read @0x80003900 QEMU add the memory range 0x80003000 to 0x80003FFF into a TLB entry.
      Then no more PMP check is done from 0x80003000 to 0x80003FFF until the TLB is flushed.
  What should be done:
      Only the range 0x80003800 to 0x80003BFF should be added to the TLB entry.

  The 4KB range is the default size of a TLB page on QEMU for RISCV.
  The minimum size that can be set is 64Bytes. However the PMP granularity can be as low as 4Bytes.

  I tested a quick fix and PMP is working as expected.
  The quick fix consist in replacing this line:
  tlb_set_page(cs, address & TARGET_PAGE_MASK, pa & TARGET_PAGE_MASK, prot, mmu_idx, TARGET_PAGE_SIZE);
  By this one in target/riscv/cpu_helper.c:
  tlb_set_page(cs, address & ~0x3, pa & ~0x3, prot, mmu_idx, size);

  This quick fix has to be optimized in order to consume less HW
  resources, as explained at the beginning.

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


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

end of thread, other threads:[~2021-04-30  9:38 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-02 17:14 [Bug 1886076] [NEW] risc-v pmp implementation error Nicolas Royer
2020-07-09 11:32 ` [Bug 1886076] " Laurent Vivier
2020-08-13 22:30 ` Alistair Francis
2020-08-13 22:31 ` Alistair Francis
2021-04-30  9:13 ` Thomas Huth

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.