All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew <andrew@fubar.geek.nz>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] [Bug 1713066] [NEW] Incorrect handling of aarch64 ldp in some cases
Date: Fri, 25 Aug 2017 13:50:59 -0000	[thread overview]
Message-ID: <150366905912.16996.8020711454083281212.malonedeb@gac.canonical.com> (raw)

Public bug reported:

In some cases the ldp instruction (and presumably other multi-register
loads and stores) can behave incorrectly.

Given the following instruction:
ldp x0, x1, [x0]

This will load two 64 bit values from memory, however if each location
to load is on a different page and the second page is unmapped this will
raise an exception. When this happens x0 has already been updated so
after the exception handler has run the operating system will try to
rerun the instruction. QEMU will now try to perform an invalid load and
raise a new exception.

I believe this is incorrect as section D.1.14.5 of the ARMv8 reference
manual B.a states that, on taking an exception, registers used in the
generation of addresses are restored to their initial value, so x0
shouldn't be changed, where x1 can be un an unknown state.

I found the issue running FreeBSD with the cortex-strings implementation
of memcpy. This uses a similar instruction when copying between 64 and
96 bytes.

I've observed this on:
QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.14), Copyright (c) 2003-2008 Fabrice Bellard

And checked I still get the same behaviour on:
QEMU emulator version 2.9.94 (v2.10.0-rc4-dirty)
Git revision: 248b23735645f7cbb503d9be6f5bf825f2a603ab

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

Title:
  Incorrect handling of aarch64 ldp in some cases

Status in QEMU:
  New

Bug description:
  In some cases the ldp instruction (and presumably other multi-register
  loads and stores) can behave incorrectly.

  Given the following instruction:
  ldp x0, x1, [x0]

  This will load two 64 bit values from memory, however if each location
  to load is on a different page and the second page is unmapped this
  will raise an exception. When this happens x0 has already been updated
  so after the exception handler has run the operating system will try
  to rerun the instruction. QEMU will now try to perform an invalid load
  and raise a new exception.

  I believe this is incorrect as section D.1.14.5 of the ARMv8 reference
  manual B.a states that, on taking an exception, registers used in the
  generation of addresses are restored to their initial value, so x0
  shouldn't be changed, where x1 can be un an unknown state.

  I found the issue running FreeBSD with the cortex-strings
  implementation of memcpy. This uses a similar instruction when copying
  between 64 and 96 bytes.

  I've observed this on:
  QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.14), Copyright (c) 2003-2008 Fabrice Bellard

  And checked I still get the same behaviour on:
  QEMU emulator version 2.9.94 (v2.10.0-rc4-dirty)
  Git revision: 248b23735645f7cbb503d9be6f5bf825f2a603ab

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

             reply	other threads:[~2017-08-25 14:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-25 13:50 Andrew [this message]
2017-08-25 15:41 ` [Qemu-devel] [Bug 1713066] [NEW] Incorrect handling of aarch64 ldp in some cases Peter Maydell
2017-08-25 20:42 ` [Qemu-devel] [Bug 1713066] " Gergely Czuczy
2017-08-29 11:15 ` Andrew
2017-08-29 11:47 ` Peter Maydell
2017-08-30 12:38 ` Andrew
2017-09-04 17:39 ` Peter Maydell
2017-12-15 15:59 ` Thomas Huth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=150366905912.16996.8020711454083281212.malonedeb@gac.canonical.com \
    --to=andrew@fubar.geek.nz \
    --cc=1713066@bugs.launchpad.net \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.