qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Bug 1906295] [NEW] Implementation of exclusive monitor in ARM
@ 2020-11-30 18:36 JIANG Muhui
  2020-11-30 19:49 ` [Bug 1906295] " Peter Maydell
  0 siblings, 1 reply; 2+ messages in thread
From: JIANG Muhui @ 2020-11-30 18:36 UTC (permalink / raw)
  To: qemu-devel

Public bug reported:

Hi

I refer to the implementation of exclusive monitor in ARM32. For
instruction like STREX Rx,Ry,[Rz], we need to check whether the address
[Rz] is in exclusive state. If not, we set the value Rx as 1 without
doing the store operation. However, I noticed that QEMU will not check
whether the address that Rz points to is a legal address or not. If the
value of Rz is 0x0 but it is not in exclusive state. QEMU will set Rx as
1 and continue to execute the following instructions.

However, physical devices will check the value of Rz. If Rz is an illegal address (e.g., 0x0), a SIGSEGV signal will be raised even the address is not in exclusive state. I searched many documentation about ARM and it seems that manual of ARM specification does not specify the implementation of exclusive monitor in detail. I am not sure which one is the right behavior. 
Should QEMU add this check? This might not be a mistake. However, should it be better if QEMU has the same behavior as a physical device? Feel free if you need a testcase. Many thanks

Regards
Muhui

** Affects: qemu
     Importance: Undecided
         Status: New

** Summary changed:

- Improper implementation of exclusive monitor in ARM
+ Implementation of exclusive monitor in ARM

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

Title:
  Implementation of exclusive monitor in ARM

Status in QEMU:
  New

Bug description:
  Hi

  I refer to the implementation of exclusive monitor in ARM32. For
  instruction like STREX Rx,Ry,[Rz], we need to check whether the
  address [Rz] is in exclusive state. If not, we set the value Rx as 1
  without doing the store operation. However, I noticed that QEMU will
  not check whether the address that Rz points to is a legal address or
  not. If the value of Rz is 0x0 but it is not in exclusive state. QEMU
  will set Rx as 1 and continue to execute the following instructions.

  However, physical devices will check the value of Rz. If Rz is an illegal address (e.g., 0x0), a SIGSEGV signal will be raised even the address is not in exclusive state. I searched many documentation about ARM and it seems that manual of ARM specification does not specify the implementation of exclusive monitor in detail. I am not sure which one is the right behavior. 
  Should QEMU add this check? This might not be a mistake. However, should it be better if QEMU has the same behavior as a physical device? Feel free if you need a testcase. Many thanks

  Regards
  Muhui

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


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

* [Bug 1906295] Re: Implementation of exclusive monitor in ARM
  2020-11-30 18:36 [Bug 1906295] [NEW] Implementation of exclusive monitor in ARM JIANG Muhui
@ 2020-11-30 19:49 ` Peter Maydell
  0 siblings, 0 replies; 2+ messages in thread
From: Peter Maydell @ 2020-11-30 19:49 UTC (permalink / raw)
  To: qemu-devel

QEMU's load/store exclusive implementation is known to not be
architecturally compliant. Most notably, it works on virtual addresses
and the architecture specifies that exclusives are supposed to work on
physical addresses. We provide a "good enough for what real code (not
weird test cases) needs" implementation.

However, in this specific case, we're within the architectural
requirements. In the ARMv8A Arm ARM (DDI0487F.c) the pseudocode
AArch32.ExclusiveMonitorsPass() function has this comment:

// It is IMPLEMENTATION DEFINED whether the detection of memory aborts happens
// before or after the check on the local Exclusives monitor. As a result a failure
// of the local monitor can occur on some implementations even if the memory
// access would give a memory about.

In other words, it's up to the implementation whether it detects and
reports the invalid address first. QEMU's implementation chooses not to.


** 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/1906295

Title:
  Implementation of exclusive monitor in ARM

Status in QEMU:
  Invalid

Bug description:
  Hi

  I refer to the implementation of exclusive monitor in ARM32. For
  instruction like STREX Rx,Ry,[Rz], we need to check whether the
  address [Rz] is in exclusive state. If not, we set the value Rx as 1
  without doing the store operation. However, I noticed that QEMU will
  not check whether the address that Rz points to is a legal address or
  not. If the value of Rz is 0x0 but it is not in exclusive state. QEMU
  will set Rx as 1 and continue to execute the following instructions.

  However, physical devices will check the value of Rz. If Rz is an illegal address (e.g., 0x0), a SIGSEGV signal will be raised even the address is not in exclusive state. I searched many documentation about ARM and it seems that manual of ARM specification does not specify the implementation of exclusive monitor in detail. I am not sure which one is the right behavior. 
  Should QEMU add this check? This might not be a mistake. However, should it be better if QEMU has the same behavior as a physical device? Feel free if you need a testcase. Many thanks

  Regards
  Muhui

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


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

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

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-30 18:36 [Bug 1906295] [NEW] Implementation of exclusive monitor in ARM JIANG Muhui
2020-11-30 19:49 ` [Bug 1906295] " Peter Maydell

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).