All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Howard <cvz185@web.de>
To: qemu-devel@nongnu.org
Subject: Re: Possible bug when setting aarch64 watchpoints
Date: Sun, 24 Apr 2022 14:27:10 +0200	[thread overview]
Message-ID: <8A733777-02DE-45C2-930D-A83948C804BA@web.de> (raw)
In-Reply-To: <DF7731C2-424F-4438-BD46-A09CAAE21835@web.de>

Sorry, I need to correct my previous post:



If I set

DBGWVR0_EL1 = 1<<23			// ie. 0x00800000

and

DBGWCR0_EL1 = 0x17<<24 | 0xFF<<5 | 0b11<<3 | 0b11<<1 | 0b1<<0		// ie. MASK = 23 = 0b10111

and then access  memory [0x0080007F]  I get a watchpoint exception. (ie. watchpoints ARE working/enabled)

But if I access [0x00800080] I *don’t* get an exception.

**If the MASK field gets set to 0b0111 instead of 0b10111 then only the bottom 7 bits of the address get masked (instead of 23) and the masked address isn’t 0x00800000, and the exception won’t be triggered.**

(if I *attempt* to set the MASK to 0b11111, but it actually gets set to 0b01111, then I get the behaviour quoted below).


> On 24. Apr 2022, at 13:40, Chris Howard <cvz185@web.de> wrote:
> 
> Hi, I’m new to qemu (and even bug-reporting) so apologies in advance…
> 
> The MASK field in DBGWCRx_EL1 is **5** bits wide [28:24].
> 
> In target/arm/kvm64.c I found the line:
> 
> wp.wcr = deposit32(wp.wcr, 24, 4, bits);		// ie **4** bits instead of **5**
> 
> 
> If it’s not copying (or calculating?) the number of bits correctly this would explain the behaviour I’m seeing:
> 
> If I set
> 
> DBGWVR0_EL1 = 0x00800000
> 
> and
> 
> DBGWCR0_EL1 = 0x1F<<24 | 0xFF<<5 | 0b11<<3 | 0b11<<1 | 0b1<<0
> 
> and then access  memory [0x00807FFF]  I get a watchpoint exception. (ie. watchpoints ARE working/enabled)
> 
> But if I access [0x008080000] I *don’t* get an exception.
> 
> **If the MASK field gets set to 0b1111 instead of 0b11111 then only the bottom 15 bits of the address get masked (instead of 31) and the masked address isn’t 0x00800000, and the exception won’t be triggered.**
> 
> 
> Unfortunately, changing the 4 to a 5 and recompiling had no effect :-(
> 
> I may well have misunderstood something. :-/
> 
> —Chris



  reply	other threads:[~2022-04-24 12:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-24 11:40 Possible bug when setting aarch64 watchpoints Chris Howard
2022-04-24 12:27 ` Chris Howard [this message]
2022-04-27  5:14 ` Richard Henderson

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=8A733777-02DE-45C2-930D-A83948C804BA@web.de \
    --to=cvz185@web.de \
    --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.