hen attempting to read such large files in one
syscall.
Fix the first problem by switching to 64-bit types for file sizes,
and fix the second by introducing a loop around the read syscall.
Signed-off-by: Peter Collingbourne
---
hw/core/generic-loader.c | 2 +-
hw/core/loader.c |
MTE3 introduces an asymmetric tag checking mode, in which loads are
checked synchronously and stores are checked asynchronously. Add
support for it.
Signed-off-by: Peter Collingbourne
Reviewed-by: Richard Henderson
---
v2:
- remove unused argument
target/arm/cpu64.c | 2 +-
target/arm
MTE3 introduces an asymmetric tag checking mode, in which loads are
checked synchronously and stores are checked asynchronously. Add
support for it.
Signed-off-by: Peter Collingbourne
---
target/arm/cpu64.c | 2 +-
target/arm/mte_helper.c | 83 ++---
2
I happened to notice that you're moving your bug tracker to gitlab so I
refiled this issue over there: https://gitlab.com/qemu-
project/qemu/-/issues/403
** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #403
https://gitlab.com/qemu-project/qemu/-/issues/403
--
You received this bug n
(s/PR_MTE_TCF_ASYNC/PR_MTE_TCF_SYNC/g in the above program -- but the
actual constant is correct)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1921948
Title:
MTE tags not checked properly for unal
It looks like there's still a bug here: I'm seeing false positive MTE
faults for unaligned accesses that touch multiple pages. This userspace
assembly program demonstrates the problem, but for some reason it only
reproduces some of the time for me:
.arch_extension memtag
.globl _start
_start:
mov
The flags that you need to pass to FVP to enable MTE are listed near the
end of the README here:
https://cs.android.com/android/platform/superproject/+/master:device/generic/goldfish/fvpbase/README.md
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subs
(acctype), so
that unprivileged instructions use SCTLR_EL1.TCF0 and TFSRE0_EL1.
The exception type for synchronous tag check faults remains unchanged.
This patch implements the described change by partially reverting
commits 50244cc76abc and cc97b0019bb5.
Signed-off-by: Peter Collingbourne
On Thu, Jan 28, 2021 at 8:25 AM Peter Maydell wrote:
>
> On Wed, 20 Jan 2021 at 22:44, Alexander Graf wrote:
> >
> > From: Peter Collingbourne
> >
> > Sleep on WFI until the VTIMER is due but allow ourselves to be woken
> > up on IPI.
> >
> >
Thanks for the patch. I've verified that it fixes the assertion failure
with both TCF0=1 and TCF0=2.
You can disregard the kernel panic from comment #1 since it turns out
that it was from an older build of QEMU that did not have 50244cc76abc.
--
You received this bug notification because you are
Thanks, I will try that patch.
Apologies, the instructions assume some familiarity with building
Android. You will find instructions for downloading the "repo" tool and
the Android source tree here:
https://source.android.com/setup/build/downloading
This isn't the first time I've received this k
This isn't a fork of qemu, it was an upstream checkout based on commit
944fdc5e27a5b5adbb765891e8e70e88ba9a00ec (well, okay, I did have the ARM
HVF series applied to this checkout, but I wouldn't expect that to
affect TCG). I verified that 50244cc76abc is present in my checkout.
Let me see if I ca
The workaround patch above is insufficient if I change userspace to set
TCF0=1. With that I get a kernel panic:
[ 13.336255][C0] Bad mode in Synchronous Abort handler detected on CPU0,
code 0x9211 -- DABT (lower EL)
[ 13.337437][C0] CPU: 0 PID: 1 Comm: init Not tainted
5.10.0-rc7
Public bug reported:
I am trying to boot Android (just the non-GUI parts for now) under QEMU
with MTE enabled. This can be done by following the instructions here to
build the fvp-eng target with MTE support:
https://cs.android.com/android/platform/superproject/+/master:device/generic/goldfish/fv
On Thu, Dec 3, 2020 at 1:41 AM Roman Bolshakov wrote:
>
> On Mon, Nov 30, 2020 at 04:00:11PM -0800, Peter Collingbourne wrote:
> > On Mon, Nov 30, 2020 at 3:18 PM Alexander Graf wrote:
> > >
> > >
> > > On 01.12.20 00:01, Peter Collingbourne wrote:
On Thu, Dec 3, 2020 at 2:12 AM Roman Bolshakov wrote:
>
> On Tue, Dec 01, 2020 at 10:59:50AM -0800, Peter Collingbourne wrote:
> > On Tue, Dec 1, 2020 at 3:16 AM Alexander Graf wrote:
> > >
> > > Hi Peter,
> > >
> > > On 01.12.20 09:21, Peter Col
On Thu, Dec 3, 2020 at 2:39 AM Roman Bolshakov wrote:
>
> On Wed, Dec 02, 2020 at 08:04:06PM +0100, Alexander Graf wrote:
> > From: Peter Collingbourne
> >
> > Sleep on WFI until the VTIMER is due but allow ourselves to be woken
> > up on IPI.
> >
&g
On Wed, Dec 2, 2020 at 3:26 PM Frank Yang wrote:
>
>
>
> On Wed, Dec 2, 2020 at 2:57 PM Alexander Graf wrote:
>>
>>
>> On 02.12.20 23:46, Frank Yang wrote:
>>
>>
>>
>> On Wed, Dec 2, 2020 at 2:28 PM Alexander Graf wrote:
>>>
>>>
>>> On 02.12.20 23:19, Frank Yang wrote:
>>>
>>>
>>> From downstrea
On Wed, Dec 2, 2020 at 2:57 PM Alexander Graf wrote:
>
>
> On 02.12.20 23:46, Frank Yang wrote:
>
>
>
> On Wed, Dec 2, 2020 at 2:28 PM Alexander Graf wrote:
>>
>>
>> On 02.12.20 23:19, Frank Yang wrote:
>>
>>
>> From downstream:
>> https://android-review.googlesource.com/c/platform/external/qemu
On Wed, Dec 2, 2020 at 10:49 AM Alexander Graf wrote:
>
>
> On 02.12.20 05:44, Peter Collingbourne wrote:
> > Sleep on WFI until the VTIMER is due but allow ourselves to be woken
> > up on IPI.
> >
> > Signed-off-by: Peter Collingbourne
> > ---
> &g
On Tue, Dec 1, 2020 at 5:53 PM Alexander Graf wrote:
>
>
> On 02.12.20 02:19, Peter Collingbourne wrote:
> > On Tue, Dec 1, 2020 at 2:04 PM Alexander Graf wrote:
> >>
> >> On 01.12.20 19:59, Peter Collingbourne wrote:
> >>> On Tue, Dec 1, 2020 at 3
Sleep on WFI until the VTIMER is due but allow ourselves to be woken
up on IPI.
Signed-off-by: Peter Collingbourne
---
v3:
- move the simplified locking to a separate patch
- spin on sleep <2ms
v2:
- simplify locking further
- wait indefinitely on disabled or masked timers
accel/hvf/
From: Alexander Graf
This reverts commit 926a35700f0c14d6b95cbf8c3c3cce55ec7ffc3e.
You can just drop patch 3 of your v2 instead of taking this commit.
---
accel/hvf/hvf-cpus.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/accel/hvf/hvf-cpus.c b/accel/hvf/hvf-cpus.c
index 4360f64671..e613c2
- Stop setting current_cpu
- Remove the previous WFx handler
- Simplify locking
- Remove the unused ret variable in hvf_vcpu_exec
Signed-off-by: Peter Collingbourne
---
include/sysemu/hvf_int.h | 2 -
target/arm/hvf/hvf.c | 106 ++-
2 files changed, 5
On Tue, Dec 1, 2020 at 5:54 PM Alexander Graf wrote:
>
>
> On 02.12.20 02:52, Peter Collingbourne wrote:
> > On Tue, Dec 1, 2020 at 5:39 PM Alexander Graf wrote:
> >>
> >> On 02.12.20 02:32, Peter Collingbourne wrote:
> >>> On Tue, Dec 1, 2020 at 3:24
On Tue, Dec 1, 2020 at 5:39 PM Alexander Graf wrote:
>
>
> On 02.12.20 02:32, Peter Collingbourne wrote:
> > On Tue, Dec 1, 2020 at 3:24 PM Alexander Graf wrote:
> >>
> >> On 01.12.20 22:00, Peter Collingbourne wrote:
> >>> Sleep on WFx until the
On Tue, Dec 1, 2020 at 3:24 PM Alexander Graf wrote:
>
>
> On 01.12.20 22:00, Peter Collingbourne wrote:
> > Sleep on WFx until the VTIMER is due but allow ourselves to be woken
> > up on IPI.
> >
> > Signed-off-by: Peter Collingbourne
> > ---
> >
On Tue, Dec 1, 2020 at 2:04 PM Alexander Graf wrote:
>
>
> On 01.12.20 19:59, Peter Collingbourne wrote:
> > On Tue, Dec 1, 2020 at 3:16 AM Alexander Graf wrote:
> >> Hi Peter,
> >>
> >> On 01.12.20 09:21, Peter Collingbourne wrote:
> >>> Sl
On Tue, Dec 1, 2020 at 2:09 PM Alexander Graf wrote:
>
>
> On 01.12.20 21:03, Peter Collingbourne wrote:
> > On Tue, Dec 1, 2020 at 8:26 AM Alexander Graf wrote:
> >>
> >> On 01.12.20 09:21, Peter Collingbourne wrote:
> >>> Sleep on WFx until the
On Tue, Dec 1, 2020 at 2:11 PM Alexander Graf wrote:
>
>
> On 01.12.20 22:00, Peter Collingbourne wrote:
> > This variable is already being set by the generic HVF code and it's a
> > thread-local variable so I don't see how it can be overwritten.
> >
&
This variable is already being set by the generic HVF code and it's a
thread-local variable so I don't see how it can be overwritten.
Signed-off-by: Peter Collingbourne
---
target/arm/hvf/hvf.c | 8
1 file changed, 8 deletions(-)
diff --git a/target/arm/hvf/hvf.c b/targ
Sleep on WFx until the VTIMER is due but allow ourselves to be woken
up on IPI.
Signed-off-by: Peter Collingbourne
---
v2:
- simplify locking further
- wait indefinitely on disabled or masked timers
accel/hvf/hvf-cpus.c | 5 +-
include/sysemu/hvf_int.h | 3 +-
target/arm/hvf/hvf.c
On Tue, Dec 1, 2020 at 8:26 AM Alexander Graf wrote:
>
>
> On 01.12.20 09:21, Peter Collingbourne wrote:
> > Sleep on WFx until the VTIMER is due but allow ourselves to be woken
> > up on IPI.
> >
> > Signed-off-by: Peter Collingbourne
> > ---
> > Al
On Tue, Dec 1, 2020 at 3:16 AM Alexander Graf wrote:
>
> Hi Peter,
>
> On 01.12.20 09:21, Peter Collingbourne wrote:
> > Sleep on WFx until the VTIMER is due but allow ourselves to be woken
> > up on IPI.
> >
> > Signed-off-by: Peter Collingbourne
>
>
&
Sleep on WFx until the VTIMER is due but allow ourselves to be woken
up on IPI.
Signed-off-by: Peter Collingbourne
---
Alexander Graf wrote:
> I would love to take a patch from you here :). I'll still be stuck for a
> while with the sysreg sync rework that Peter asked for before I ca
On Mon, Nov 30, 2020 at 3:18 PM Alexander Graf wrote:
>
>
> On 01.12.20 00:01, Peter Collingbourne wrote:
> > On Mon, Nov 30, 2020 at 1:40 PM Alexander Graf wrote:
> >> Hi Peter,
> >>
> >> On 30.11.20 22:08, Peter Collingbourne wrote:
> >>&
On Mon, Nov 30, 2020 at 1:40 PM Alexander Graf wrote:
>
> Hi Peter,
>
> On 30.11.20 22:08, Peter Collingbourne wrote:
> > On Mon, Nov 30, 2020 at 12:56 PM Frank Yang wrote:
> >>
> >>
> >> On Mon, Nov 30, 2020 at 12:34 PM Alexander Graf wrote:
>
oll interval (like KVM
>> does) in handling WFI:
>>
>> https://android-review.googlesource.com/c/platform/external/qemu/+/1512501
>>
>> This is loosely inspired by
>> https://elixir.bootlin.com/linux/v5.10-rc6/source/virt/kvm/kvm_main.c#L2766
>> which does
/1512501
>>
>> This is loosely inspired by
>> https://elixir.bootlin.com/linux/v5.10-rc6/source/virt/kvm/kvm_main.c#L2766
>> which does seem to specify a poll interval.
>>
>> It would be cool if we could have a lightweight way to enter sleep and
>> restart the vcp
On Tue, Aug 4, 2020 at 8:41 AM Richard Henderson
wrote:
>
> On 8/3/20 5:21 PM, Peter Collingbourne wrote:
> > On Mon, Aug 3, 2020 at 3:27 PM Peter Collingbourne wrote:
> >>
> >> These instructions use zero as the discriminator, not SP.
> >
> > Oh, the
These instructions use zero as the discriminator, not SP.
Signed-off-by: Peter Collingbourne
---
v2:
- fixed commit message
target/arm/translate-a64.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index
The name disas_ldst_pac is misleading as it implies the existence
of authenticating store instructions, so rename it to avoid that
implication.
Signed-off-by: Peter Collingbourne
---
target/arm/translate-a64.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/target/arm
On Mon, Aug 3, 2020 at 3:27 PM Peter Collingbourne wrote:
>
> These instructions use zero as the discriminator, not SP.
Oh, there is no such thing as STRAA/STRAB. I must have been confused
by the name of the function, disas_ldst_pac. I will send a v2 with a
fixed commit message, and a
These instructions use zero as the discriminator, not SP.
Signed-off-by: Peter Collingbourne
---
target/arm/translate-a64.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index 8c0764957c..c996ca1393 100644
--- a
With those two patches applied I can no longer reproduce the problem,
thanks!
For posterity, this is how I've been reproducing the problem:
1. Build a Linux kernel with this patch applied:
https://patchwork.kernel.org/patch/11435077/
2. Run this program under the kernel:
#include
#include
#in
Public bug reported:
The ARM Architecture Reference Manual provides the following for
FAR_EL1:
"For a Data Abort or Watchpoint exception, if address tagging is enabled
for the address accessed by the data access that caused the exception,
then this field includes the tag."
However, I have found
46 matches
Mail list logo
