addrsp,0x8
23f9d9: c3 ret
23f9da: 48 8b 54 24 08 movrdx,QWORD PTR [rsp+0x8]
23f9df: be 09 00 00 00 movesi,0x9
23f9e4: e8 a7 df ff ff call 23d990
Thanks!
Tested-by: Idan Horowi
On 19/12/2022 14:19, Alex Bennée wrote:
> According to LinkedIn Idan works at IBM. Please confirm if you want
> these contributions counted under IBM or as personal contributions.
>
> Signed-off-by: Alex Bennée
> Cc: Idan Horowitz
> ---
> contrib/gitdm/group-map-ibm | 1 +
ve2_zip_q);
> + vec_full_reg_offset(s, a->rn),
> + vec_full_reg_offset(s, a->rm),
> + vsz, vsz, high_ofs, gen_helper_sve2_zip_q);
> }
> return true;
> }
> --
> 2.34.1
>
>
Best Regards, Idan Horowitz
On Wed, 26 Jan 2022 at 23:43, Richard Henderson
wrote:
>
> Reviewed-by: Richard Henderson
>
> r~
Hey, I believe this patch might have accidentally been missed?
Thanks,
Idan Horowitz
undo
the revert (as Alistair already removed it from the apply-next tree),
since my original patch fixes buggy behaviour that is blocking the
testing of some embedded software on QEMU.
Idan Horowitz
tion here is to:
1. Report the issue to the linux kernel mailing list and/or contribute
a patch that adds said missing sfence.vma following the SATP write.
(Atish: Are you able to test if adding an sfence.vma in your kernel
build fixes the issue?)
2. Restore the patch
>
> --
> Regards,
> Atish
Idan Horowitz
rors you're seeing simply mean that these addresses are not
translated by the new address translation context set by the write to
the satp.
To be honest I don't immediately see how this could be caused by the
patch, as it modifies the behaviour of the sfence.vma instruction, and
there are none in your trace.
Idan Horowitz
ndeed, I initially found the issue when a test case passed on arm IP
but raised a data abort in QEMU.
Since fixing this issue solved the inconsistency, I believe this is
the intended behaviour and not a spec bug.
>
> r~
Idan Horowitz
While not mentioned anywhere in the actual specification text, the
HCR_EL2.ATA bit is treated as '1' when EL2 is disabled at the current
security state. This can be observed in the psuedo-code implementation
of AArch64.AllocationTagAccessIsEnabled().
Signed-off-by: Idan Horowitz
---
.SA is 1."
>
> Sorry but I don't see any reason to check the SW bit here.
That still does not cover the case of NSA=0, NSW=0, SA=0, SW=1.
> --
> Реми Дёни-Курмон
> http://www.remlab.net/
Idan Horowitz
As per the AArch64.S2Walk() psuedo-code in the ARMv8 ARM, the final
decision as to the output address's PA space based on the SA/SW/NSA/NSA
bits needs to take the input IPA's PA space into account, and not the
PA space of the result of the stage 2 walk itself.
Signed-off-by: Ida
As per the AArch64.SS2OutputPASpace() psuedo-code in the ARMv8 ARM when the
PA space of the IPA is non secure, the output PA space is secure if and only
if all of the bits VTCR., VSTCR. are not set.
Signed-off-by: Idan Horowitz
---
target/arm/helper.c | 2 +-
1 file changed, 1 insertion(+), 1
missing for the final stage 2 walk.
Signed-off-by: Idan Horowitz
---
target/arm/helper.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/target/arm/helper.c b/target/arm/helper.c
index d0265b760f..e2695e846a 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -12657,6
Idan Horowitz (3):
target/arm: Check VSTCR.SW when assigning the stage 2 output PA space
target/arm: Take VSTCR.SW, VTCR.NSW into account in final stage 2 walk
target/arm: Determine final stage 2 output PA space based on original
IPA
target/arm/helper.c | 16 ++--
1 file
If the pages which control the translation of the currently executing
instructions are changed, and then the TLB is flushed using sfence.vma
we have to exit the current TB early, to ensure we don't execute stale
instructions.
Signed-off-by: Idan Horowitz
---
target/riscv/insn_
time with the review.
>
> thanks
> -- PMM
Regards,
Idan Horowitz
eir
heavy access functions, so this is an attempt at simplifying them.
>
> thanks
> -- PMM
Regards,
Idan Horowitz
Idan Horowitz wrote:
>
> cbnz x9, 0x5168abc8
>
I forgot to include the addresses of the instructions, making this
jump undecipherable, here's the snippet again but with addresses this
time:
0x5168abb0 movkx0, #0x0
0x5168abb4 movkx0, #0x0, lsl #16
0x5168abb8 movkx0
#0xff80, lsl #32
movkx0, #0x0, lsl #48
mov x9, #0x64
str x9, [x8]
tlbirvae1, x0
ldr x9, [x8]
sub x9, x9, #0x1
str x9, [x8]
cbnz x9, 0x5168abc8
>
> --
> Alex Bennée
Idan Horowitz
This decreases qemu_clock_deadline_ns_all's share from 23.2% to 13% in a
profile of icount-enabled aarch64-softmmu.
Signed-off-by: Idan Horowitz
---
util/qemu-timer.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/util/qemu-timer.c b/util/qemu-timer.c
index f36c75e594..e56895ef55 1
The SCTLR_EL1.UCI bit only affects a subset of cache maintenance
instructions as specified by the specification. Any other cache
maintenance instructions must still be trapped from EL0.
Signed-off-by: Idan Horowitz
---
target/arm/helper.c | 68 ++---
1
Instead of taking the lock of the cpu work list in order to check if it's
empty, we can just read the head pointer atomically. This decreases
cpu_work_list_empty's share from 5% to 1.3% in a profile of icount-enabled
aarch64-softmmu.
Signed-off-by: Idan Horowitz
---
softmmu/
If the given range specifies no addresses to be flushed there's no reason
to schedule a function on all CPUs that does nothing.
Signed-off-by: Idan Horowitz
---
target/arm/helper.c | 4
1 file changed, 4 insertions(+)
diff --git a/target/arm/helper.c b/target/arm/helper.c
index cfca0
When the length of the range is large enough, clearing the whole cache is
faster than iterating over the (possibly extremely large) set of pages
contained in the range.
This mimics the pre-existing similar optimization done on the flush of the
tlb itself.
Signed-off-by: Idan Horowitz
---
accel
Ping for code review, please?
Thanks, Idan Horowitz
Some of the instructions added by the FEAT_TLBIOS extension were forgotten
when the extension was originally added to QEMU.
Fixes: 7113d618505b ("target/arm: Add support for FEAT_TLBIOS")
Signed-off-by: Idan Horowitz
---
target/arm/helper.c | 32
1 fi
26 matches
Mail list logo