Possible bug when setting aarch64 watchpoints

Possible bug when setting aarch64 watchpoints

[Chris Howard]

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

Re: Possible bug when setting aarch64 watchpoints

[Chris Howard]

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

Re: Possible bug when setting aarch64 watchpoints

[Richard Henderson]

On 4/24/22 04:40, Chris Howard 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. :-/

You're not.  It's a typo, repeated twice.  Will fix.


r~