On Fri, Jan 8, 2021 at 7:51 PM Leif Lindholm wrote:
>
> When FEAT_MTE is implemented, the AArch64 view of CTR_EL0 adds the
> TminLine field in bits [37:32].
> Extend the ctr field to be able to hold this context.
>
> Signed-off-by: Leif Lindholm
Reviewed-by: Laurent Desnogues
On Fri, Jan 8, 2021 at 7:51 PM Leif Lindholm wrote:
>
> Signed-off-by: Leif Lindholm
Reviewed-by: Laurent Desnogues
Thanks,
Laurent
> ---
> target/arm/cpu.h | 31 +++
> 1 file changed, 31 insertions(+)
>
> diff --git a/target/arm/cpu
On Thu, Dec 17, 2020 at 1:10 PM Leif Lindholm wrote:
[...]
> > > > > +FIELD(CCSIDR_EL1, LINESIZE, 0, 3)
> > > > > +FIELD(CCSIDR_EL1, ASSOCIATIVITY, 3, 21)
> > > > > +FIELD(CCSIDR_EL1, NUMSETS, 32, 24)
> > > >
> > > > The positions and sizes of the ASSOCIATIVITY and NUMSETS CCSIDR fields
> > > >
Hi Leif,
On Tue, Dec 15, 2020 at 5:49 PM Leif Lindholm wrote:
>
> On Tue, Dec 15, 2020 at 13:23:58 +0100, Laurent Desnogues wrote:
> > Hello,
> >
> > On Tue, Dec 15, 2020 at 12:51 PM Leif Lindholm wrote:
> > >
> > > Signed-off-by: Leif Lindho
On Tue, Dec 15, 2020 at 12:52 PM Leif Lindholm wrote:
>
> Add entries present in ARM DDI 0487F.c (August 2020).
>
> Signed-off-by: Leif Lindholm
Reviewed-by: Laurent Desnogues
Thanks,
Laurent
> ---
> target/arm/cpu.h | 28
> 1 file c
-by: Leif Lindholm
Reviewed-by: Laurent Desnogues
Thanks,
Laurent
> ---
> target/arm/cpu.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index 5e3cf77ec7..fadd1a47df 100644
> --- a/target/arm/cpu.h
> +++ b/tar
On Tue, Dec 15, 2020 at 12:51 PM Leif Lindholm wrote:
>
> Add entries present in ARM DDI 0487F.c (August 2020).
>
> Signed-off-by: Leif Lindholm
Reviewed-by: Laurent Desnogues
Thanks,
Laurent
> ---
> target/arm/cpu.h | 15 +++
> 1 file changed, 15 inserti
On Tue, Dec 15, 2020 at 12:51 PM Leif Lindholm wrote:
>
> SBSS -> SSBS
>
> Signed-off-by: Leif Lindholm
Reviewed-by: Laurent Desnogues
Thanks,
Laurent
> ---
> target/arm/cpu.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/targe
Hello,
On Tue, Dec 15, 2020 at 12:51 PM Leif Lindholm wrote:
>
> Signed-off-by: Leif Lindholm
> ---
> target/arm/cpu.h | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index fadd1a47df..90ba707b64 100644
> ---
On Tue, Jun 2, 2020 at 3:13 PM tugouxp <13824125...@163.com> wrote:
>
> HI guys:
>i am stucked by the following code,and i can find document illustrations
> this nowhere.
>what does the "leul" stands for? and the postfix 10 means what？
That should be little-endian unsigned long (where
On Sat, May 9, 2020 at 2:38 PM Aleksandar Markovic
wrote:
>
> суб, 9. мај 2020. у 13:37 Laurent Desnogues
> је написао/ла:
> >
> > On Sat, May 9, 2020 at 12:17 PM Aleksandar Markovic
> > wrote:
> > > сре, 6. мај 2020. у 13:26 Alex Bennée је
> > >
On Sat, May 9, 2020 at 12:17 PM Aleksandar Markovic
wrote:
> сре, 6. мај 2020. у 13:26 Alex Bennée је написао/ла:
>
> > This is very much driven by how much code generation vs running you see.
> > In most of my personal benchmarks I never really notice code generation
> > because I give my
On Thu, May 7, 2020 at 7:23 PM Richard Henderson
wrote:
>
> DUP (indexed) can duplicate 128-bit elements, so using esz
> unconditionally can assert in tcg_gen_gvec_dup_imm.
>
> Fixes: 8711e71f9cbb
> Reported-by: Laurent Desnogues
> Signed-off-by: Richard Henderson
Hello,
On Wed, May 6, 2020 at 8:30 PM Richard Henderson
wrote:
>
> In a few cases, we're able to remove some manual replication.
>
> Reviewed-by: Alex Bennée
> Signed-off-by: Richard Henderson
> ---
> target/arm/translate-a64.c | 10 +-
> target/arm/translate-sve.c | 12 +---
>
21: error: conversion from ‘uint64_t’ {aka ‘long
> unsigned int’} to ‘uint32_t’ {aka ‘unsigned int’} may change value
> [-Werror=conversion]
> 628 | cpu->midr = t;
> | ^
>
> Suggested-by: Laurent Desnogues
> Suggested-by: Peter May
21: error: conversion from ‘uint64_t’ {aka ‘long
> unsigned int’} to ‘uint32_t’ {aka ‘unsigned int’} may change value
> [-Werror=conversion]
> 628 | cpu->midr = t;
> | ^
>
> Suggested-by: Laurent Desnogues
> Suggested-by: Peter May
On Thu, Apr 23, 2020 at 5:19 PM Richard Henderson
wrote:
>
> On 4/23/20 6:59 AM, Laurent Desnogues wrote:
> > 2. sve_zip_p
> >
> > This generates extraneous data in the higher part of the result.
> >
> > I hit this when I got a wrong result on an instruction t
t midr then:
Reviewed-by: Laurent Desnogues
Thanks,
Laurent
> This fixes when compiling with -Werror=conversion:
>
> target/arm/cpu64.c: In function ‘aarch64_max_initfn’:
> target/arm/cpu64.c:628:21: error: conversion from ‘uint64_t’ {aka ‘long
> unsigned int’} to ‘uint32_t’ {ak
e right-sized variable.
>
> Fixes: 3bec78447a958d481991
> Signed-off-by: Peter Maydell
Reviewed-by: Laurent Desnogues
Thanks,
Laurent
> ---
> target/arm/cpu64.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
> in
g. Fix the typo.
>
> Fixes: 41a4bf1feab098da4cd
> Reported-by: Laurent Desnogues
> Signed-off-by: Peter Maydell
Reviewed-by: Laurent Desnogues
Thanks,
Laurent
> ---
> maybe 5.0 just because it's so trivial. I dunno...
>
> There's also an error where we use the uint32_t u vari
On Tue, Apr 14, 2020 at 1:19 AM Richard Henderson
wrote:
>
> On 4/13/20 9:15 AM, Laurent Desnogues wrote:
> > On Fri, Mar 27, 2020 at 12:18 AM Richard Henderson
> > wrote:
> > [...]
> >> diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
> &g
On Fri, Mar 27, 2020 at 12:20 AM Richard Henderson
wrote:
[...]
> diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
> index b5afa34efe..a3653007ac 100644
> --- a/target/arm/sve_helper.c
> +++ b/target/arm/sve_helper.c
> @@ -1289,6 +1289,48 @@ DO_BITPERM(sve2_bgrp_d, uint64_t,
On Fri, Mar 27, 2020 at 12:17 AM Richard Henderson
wrote:
[...]
> diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
> index a0995d95c7..aa330f75c3 100644
> --- a/target/arm/sve_helper.c
> +++ b/target/arm/sve_helper.c
[...]
> +void HELPER(sve2_adcl_d)(void *vd, void *va, void *vn,
On Fri, Mar 27, 2020 at 12:18 AM Richard Henderson
wrote:
[...]
> diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
> index a3653007ac..a0995d95c7 100644
> --- a/target/arm/sve_helper.c
> +++ b/target/arm/sve_helper.c
> @@ -1216,6 +1216,30 @@ DO_ZZZ_NTB(sve2_eoril_d, uint64_t, ,
On Fri, Mar 27, 2020 at 12:17 AM Richard Henderson
wrote:
[...]
> diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
> index 7d7a59f620..44503626e4 100644
> --- a/target/arm/sve_helper.c
> +++ b/target/arm/sve_helper.c
> @@ -1131,6 +1131,36 @@ DO_ZZZ_TB(sve2_uabdl_d, uint64_t,
On Fri, Mar 27, 2020 at 12:09 AM Richard Henderson
wrote:
[...]
> diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
> index bee00eaa44..7d7a59f620 100644
> --- a/target/arm/sve_helper.c
> +++ b/target/arm/sve_helper.c
> @@ -1088,6 +1088,49 @@ DO_ZZW(sve_lsl_zzw_s, uint32_t, uint64_t,
On Fri, Mar 27, 2020 at 12:16 AM Richard Henderson
wrote:
[...]
> diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
> index 5d75aed7b7..d7c181ddb8 100644
> --- a/target/arm/sve_helper.c
> +++ b/target/arm/sve_helper.c
> @@ -681,6 +681,73 @@ DO_ZPZZ_D(sve2_uhsub_zpzz_d, uint64_t,
Hello,
On Fri, Jan 24, 2020 at 1:45 AM Robert Henry wrote:
>
> I wrote a QEMU plugin for aarch64 where the insn and mem callbacks print out
> the specifics of the guest instructions as they are "executed". I expect
> this trace stream to be well behaved but it is not. By well-behaved, I
On Tue, Jan 14, 2020 at 10:09 PM Richard Henderson
wrote:
[...]
> I vaguely remember someone (Paolo?) implementing something like
> this many years ago, but clearly it never got merged.
That was me back in 2009:
https://lists.gnu.org/archive/html/qemu-devel/2009-07/msg00881.html
Glad it will
Hi Richard,
On Tue, Dec 3, 2019 at 3:35 AM Richard Henderson
wrote:
>
> At the same time, add writefn to TTBR0_EL2 and TCR_EL2.
> A later patch will update any ASID therein.
>
> Reviewed-by: Alex Bennée
> Signed-off-by: Richard Henderson
> ---
> target/arm/helper.c | 18 +-
>
Can you please provide a binary (preferably statically built or with
required shared libraries attached)?
Thanks,
Laurent
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1851095
Title:
[feature
Hello,
On Thu, Sep 12, 2019 at 8:31 PM Richard Henderson
wrote:
>
> The 32-bit product should be sign-extended, not zero-extended.
>
> Fixes: ea96b374641b
> Reported-by: Laurent Desnogues
> Signed-off-by: Richard Henderson
No more failures on my tests.
Tested-by: Laurent
Hi Richard,
On Wed, Sep 4, 2019 at 9:39 PM Richard Henderson
wrote:
>
> Since all of the inputs and outputs are i32, dispense with
> the intermediate promotion to i64 and use tcg_gen_add2_i32.
>
> Reviewed-by: Peter Maydell
> Signed-off-by: Richard Henderson
> ---
> target/arm/translate.c |
On Thu, Sep 5, 2019 at 5:24 PM Alex Bennée wrote:
>
>
> Richard Henderson writes:
>
> > This is the payoff.
> >
> > From perf record -g data of ubuntu 18 boot and shutdown:
> >
> > BEFORE:
> >
> > - 23.02% 2.82% qemu-system-aar [.] helper_lookup_tb_ptr
> >- 20.22%
of the product.
>
> Fixes: 5f8cd06ebcf5 ("target/arm: Simplify SMMLA, SMMLAR, SMMLS, SMMLSR")
> Reported-by: Laurent Desnogues
> Signed-off-by: Richard Henderson
Tested-by: Laurent Desnogues
Thanks,
Laurent
> ---
> target/arm/translate.c | 20 ++--
>
Hi Richard,
On Thu, Aug 8, 2019 at 10:28 PM Richard Henderson
wrote:
>
> All of the inputs to these instructions are 32-bits. Rather than
> extend each input to 64-bits and then extract the high 32-bits of
> the output, use tcg_gen_muls2_i32 and other 32-bit generator functions.
>
>
On Mon, Aug 26, 2019 at 5:15 PM Richard Henderson
wrote:
>
> Make this a static function private to translate.c.
> Thus we can use the same idiom between aarch64 and aarch32
> without actually sharing function implementations.
>
> Signed-off-by: Richard Henderson
Reviewed-by:
on_insn is totally different.
>
> This fixes exceptions raised from aarch64.
>
> Reported-by: Laurent Desnogues
> Signed-off-by: Richard Henderson
Reviewed-by: Laurent Desnogues
Thanks,
Laurent
> ---
> target/arm/translate-a64.h | 2 ++
> target/arm/translate.h
Hi Richard,
On Wed, Aug 7, 2019 at 6:54 AM Richard Henderson
wrote:
>
> Promote this function from aarch64 to fully general use.
> Use it to unify the code sequences for generating illegal
> opcode exceptions.
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/translate-a64.h | 2 --
On Fri, Jul 26, 2019 at 9:24 AM Alex Bennée wrote:
>
>
> Peter Maydell writes:
>
> > On Tue, 23 Jul 2019 at 12:33, Alex Bennée wrote:
[...]
> > /*
> > * Reset MIDR so the guest doesn't mistake our 'max' CPU type for a real
> > * one and try to apply errata workarounds or use impdef
Hi,
On Sat, Jul 6, 2019 at 12:40 AM Eduardo Habkost wrote:
>
> From: Like Xu
>
> The global smp variables in vl.c are completely replaced with machine
> properties.
>
> Form this commit, the smp_cpus/smp_cores/smp_threads/max_cpus are deprecated
> and only machine properties within
re we update FPSCR.
>
> Reported-by: Laurent Desnogues
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Laurent Desnogues
Tested-by: Laurent Desnogues
Thanks,
Laurent
> ---
> target/arm/vfp_helper.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> dif
Hello,
On Tue, Jul 2, 2019 at 4:18 AM Peter Maydell wrote:
>
> From: Philippe Mathieu-Daudé
>
> The vfp_set_fpscr() helper contains code specific to the host
> floating point implementation (here the SoftFloat library).
> Extract this code to vfp_set_fpscr_to_host().
>
> Signed-off-by: Philippe
On Thu, May 2, 2019 at 6:17 PM Laurent Vivier wrote:
>
> On 02/05/2019 16:58, Alex Bennée wrote:
> > The guest tends to get confused when it receives signals it doesn't
> > know about. Given the gprof magic has also set up it's own handler we
> > would do well to avoid stomping on it as well.
> >
ff-by: Alex Bennée
Tested-by: Laurent Desnogues
Thanks,
Laurent
> ---
> linux-user/exit.c| 3 +++
> linux-user/syscall.c | 3 ---
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/linux-user/exit.c b/linux-user/exit.c
> index 14e94e28fa..bdda720553 1
On Fri, Mar 8, 2019 at 11:31 AM Laurent Desnogues
wrote:
>
> Hello,
>
> On Thu, Mar 7, 2019 at 6:09 PM Richard Henderson
> wrote:
[...]
> > +static CPAccessResult access_mte(CPUARMState *env, const ARMCPRegInfo *ri,
> > + bool isr
Hello,
On Thu, Mar 7, 2019 at 6:09 PM Richard Henderson
wrote:
>
> This is TFSRE0_EL1, TFSR_EL1, TFSR_EL2, TFSR_EL3,
> RGSR_EL1, GCR_EL1, GMID_EL1, and PSTATE.TCO.
>
> Signed-off-by: Richard Henderson
> ---
> v3: Add GMID; add access_mte.
> ---
> target/arm/cpu.h | 3 ++
>
-tested it against my own understanding of what is supposed
> to go on with the file below.
I ran some tests and found no issue. Your understanding looks correct :-)
Tested-by: Laurent Desnogues
Thanks,
Laurent
>
> r~
>
>
> Richard Henderson (2):
> target/arm: Re
erything passes.
tested-by: Laurent Desnogues
Thanks,
Laurent
>
> r~
>
>
> Richard Henderson (3):
> target/arm: Rearrange disas_data_proc_reg
> target/arm: Implement ARMv8.4-CondM
> target/arm: Implement ARMv8.5-CondM
>
> target/arm/cpu.h | 10 ++
>
On Thu, Feb 14, 2019 at 3:56 PM Richard Henderson
wrote:
>
> On 2/14/19 1:16 AM, Laurent Desnogues wrote:
> > Hello,
> >
> > On Thu, Feb 14, 2019 at 5:00 AM Richard Henderson
> > wrote:
> >>
> >> Note that float16_to_float32 rightly squashe
Hi Richard,
On Thu, Feb 14, 2019 at 5:07 AM Richard Henderson
wrote:
>
> We've talked about this before, caching state to reduce the
> amount of computation that happens looking up each TB.
>
> I know that Peter has been concerned that we would not be able to
> reliably maintain all of the
Hello,
On Thu, Feb 14, 2019 at 5:00 AM Richard Henderson
wrote:
>
> Note that float16_to_float32 rightly squashes SNaN to QNaN.
> But of course pickNaNMulAdd, for ARM, selects SNaNs first.
> So we have to preserve SNaN long enough for the correct NaN
> to be selected. Thus
Hello,
On Wed, Feb 6, 2019 at 6:32 AM Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
Tested-by: Laurent Desnogues
Thanks,
Laurent
> ---
> v2: Return 0 for NaN
> ---
> target/arm/cpu.h | 10 +
> target/arm/helper.h| 2
Hello,
here are some missed undefined instructions I skipped over last time
(I had forgotten to enable FP16 support in QEMU):
- disas_simd_across_lanes: for FP16 FMAX/FMINV/FMAXNMV/FMINNMV it
should be checked that bit 0 of the size field is 0
- disas_simd_mod_imm: FP16 FMOV imm must have bit
On Tue, Feb 5, 2019 at 2:51 PM Aaron Lindsay OS
wrote:
>
> This bug was introduced in:
> commit 5ecdd3e47cadae83a62dc92b472f1fe163b56f59
> target/arm: Finish implementation of PM[X]EVCNTR and PM[X]EVTYPER
>
> Signed-off-by: Aaron Lindsay
> Reported-by: Laurent
On Tue, Feb 5, 2019 at 2:41 PM Aaron Lindsay OS
wrote:
>
> On Feb 04 20:22, Laurent Desnogues wrote:
> > Hello,
> >
> > On Tue, Dec 11, 2018 at 4:25 PM Aaron Lindsay
> > wrote:
> > >
> > > Add arrays to hold the registers, the definitions themse
Hello,
On Tue, Dec 11, 2018 at 4:25 PM Aaron Lindsay
wrote:
>
> Add arrays to hold the registers, the definitions themselves, access
> functions, and logic to reset counters when PMCR.P is set. Update
> filtering code to support counters other than PMCCNTR. Support migration
> with raw
Hello,
On Mon, Feb 4, 2019 at 6:38 AM Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/cpu.h | 10 +
> target/arm/helper.h| 2 +
> target/arm/cpu.c | 1 +
> target/arm/cpu64.c | 2 +
> target/arm/op_helper.c | 91
On Tue, Jan 29, 2019 at 3:04 PM Peter Maydell wrote:
>
> The FCMLA (by element) instruction exists in the
> "vector x indexed element" encoding group, but not in
> the "scalar x indexed element" group. Correctly UNDEF
> the unallocated encodings.
>
> Rep
l and imaginary parts are 32-bit floats, and would incorrectly
> UNDEF this encoding. (No other insns take this code path, and for
> 16-bit floats it happens that 1 << 1 and 1 + 1 are both the same).
>
> Reported-by: Laurent Desnogues
> Signed-off-by: Peter Maydell
Reviewed-by: La
Hello,
I found two issues with FCMLA decoding in AArch64 disas_simd_indexed:
- FCMLA is not available as a scalar instruction
- size is wrongly shifted by one instead of being incremented by one.
Thanks,
Laurent
re(),
> disas_fp_ccomp() and disas_fp_csel(), but missed it in disas_fp_1src(),
> disas_fp_2src(), disas_fp_3src() and disas_fp_imm().
>
> We also missed that in the fp immediate encoding the imm5 field
> must be all zeroes.
>
> Correctly UNDEF the unallocated encodings here.
>
On Fri, Jan 25, 2019 at 7:26 PM Peter Maydell wrote:
>
> In the "add/subtract (extended register)" encoding group, the "opt"
> field in bits [23:22] must be zero. Correctly UNDEF the unallocated
> encodings where this field is not zero.
>
> Reported-by: Lau
ocated encoding.
>
> Reported-by: Laurent Desnogues
> Signed-off-by: Peter Maydell
Reviewed-by: Laurent Desnogues
Thanks,
Laurent
> ---
> target/arm/translate-a64.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/arm/translate-a64.c b/target/
n ldst_multiple but not here). Correctly
> UNDEF these unallocated encodings.
>
> Reported-by: Laurent Desnogues
> Signed-off-by: Peter Maydell
Reviewed-by: Laurent Desnogues
Thanks,
Laurent
> ---
> target/arm/translate-a64.c | 11 ++-
> 1 file changed, 10 insertions(+), 1
dings where idx == 0b01
> and 0b11 as well as 0b10.
>
> Reported-by: Laurent Desnogues
> Signed-off-by: Peter Maydell
Reviewed-by: Laurent Desnogues
Thanks,
Laurent
> ---
> target/arm/translate-a64.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
hich
> have non-zeroes in those bits.
>
> Reported-by: Laurent Desnogues
> Signed-off-by: Peter Maydell
Reviewed-by: Laurent Desnogues
Thanks,
Laurent
> ---
> target/arm/translate-a64.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git
e currently
> unallocated. Correctly UNDEF these unallocated encodings.
>
> Reported-by: Laurent Desnogues
> Signed-off-by: Peter Maydell
Reviewed-by: Laurent Desnogues
Thanks,
Laurent
> ---
> target/arm/translate-a64.c | 6 +-
> 1 file changed, 5 insertions(+), 1 delet
Hello,
I did exhaustive comparisons against latest binutils and found the
following undefined instructions that QEMU fails to flag:
- in disas_b_exc_sys, before calling disas_system bits [23:22] should
be checked to be 0
- in disas_ldst_reg_imm9, PRFM is wrongly detected: PRFM is for idx =
0,
Newer versions of the library seem to deal with this
> better and modern hardware has fused operations which the library can
> use.
Thanks for taking care of this issue. The fix was tested on our
machines and it works as expected.
So:
Tested-by: Laurent Desnogues
> Reported-by: Laurent
On Fri, Nov 30, 2018 at 4:00 AM Emilio G. Cota wrote:
>
> On Thu, Nov 29, 2018 at 19:39:15 -0500, Emilio G. Cota wrote:
> > A64 and POWER9 host numbers:
> >
> > https://imgur.com/a/m6Pss99
> >
> > There's quite a bit of noise in the P9 measurements, but it's
> > a shared machine so I can't do
Hello,
On Tue, Oct 9, 2018 at 3:19 PM Edgar E. Iglesias
wrote:
>
> Another A72 related thing I wanted to check with you. A month or two ago I was
> looking at an issue with Linux running very slowly on our models.
> Something that popped up was that Linux was running a couple of spectre
>
Hello,
On Fri, Aug 17, 2018 at 6:04 PM Peter Maydell wrote:
>
> On 9 August 2018 at 05:21, Richard Henderson
> wrote:
> > Saves about 8k code size in qemu-aarch64.
> >
> > Signed-off-by: Richard Henderson
> > ---
> > target/arm/cpu.h | 8
> > 1 file changed, 8 insertions(+)
> >
> >
On Fri, Aug 10, 2018 at 9:31 PM, Richard Henderson
wrote:
> These insns require u=1; failed to include that in the switch
> cases. This probably happened during one of the rebases just
> before final commit.
>
> Fixes: d17b7cdcf4e
> Signed-off-by: Richard Henderson
Re
On Fri, Aug 10, 2018 at 9:31 PM, Richard Henderson
wrote:
> For 0x1.3p+0 + 0x1.ffep+14 = 0x1.0001fffp+15
> we dropped the sticky bit and so failed to raise inexact.
>
> Reported-by: Laurent Desnogues
> Signed-off-by: Richard Henderson
Tested-by: Laurent Desn
On Fri, Aug 10, 2018 at 9:31 PM, Richard Henderson
wrote:
> We were using the wrong flush-to-zero bit for the non-half input.
>
> Fixes: 46d33d1e3c9
> Cc: qemu-sta...@nongnu.org (3.0.1)
> Reported-by: Laurent Desnogues
> Signed-off-by: Richard Henderson
Tested-by: Laurent D
On Fri, Aug 10, 2018 at 9:31 PM, Richard Henderson
wrote:
> This makes float16_muladd correctly use FZ16 not FZ.
>
> Fixes: 6ceabaad110
> Cc: qemu-sta...@nongnu.org (3.0.1)
> Reported-by: Laurent Desnogues
> Signed-off-by: Richard Henderson
Tested-by: Laurent Desnogues
Re
re them when computing the accumulated flags.
>
> Cc: qemu-sta...@nongnu.org (3.0.1)
> Reported-by: Laurent Desnogues
> Signed-off-by: Richard Henderson
Tested-by: Laurent Desnogues
Reviewed-by: Laurent Desnogues
Laurent
> ---
> target/arm/helper.c | 6 +-
> 1 file cha
-sta...@nongnu.org (3.0.1)
> Reported-by: Laurent Desnogues
> Signed-off-by: Richard Henderson
Tested-by: Laurent Desnogues
Reviewed-by: Laurent Desnogues
Laurent
> ---
> target/arm/cpu.h| 2 +-
> target/arm/helper.c | 5 +
> 2 files changed, 6 insertions(+), 1 deletion(
infrastructure that can be reused to speed up normal
> loads -- one guest-to-host tlb lookup can be reused for the rest
> of the page.
I did not review every patch individually but tested the whole and
found no issue.
Tested-by: Laurent Desnogues
Thanks,
Laurent
>
> r~
>
>
On Thu, Aug 9, 2018 at 5:40 AM, Richard Henderson
wrote:
> The scaling should be solely on the memory operation size; the number
> of registers being loaded does not come in to the initial computation.
>
> Cc: qemu-sta...@nongnu.org (3.0.1)
> Reported-by: Laurent Desnogue
On Thu, Aug 9, 2018 at 5:40 AM, Richard Henderson
wrote:
> The immediate should be scaled by the size of the memory reference,
> not the size of the elements into which it is loaded.
>
> Cc: qemu-sta...@nongnu.org (3.0.1)
> Reported-by: Laurent Desnogues
> Signed-off-by:
g to use int.
>
> Cc: qemu-sta...@nongnu.org (3.0.1)
> Reported-by: Laurent Desnogues
> Signed-off-by: Richard Henderson
Tested-by: Laurent Desnogues
Reviewed-by: Laurent Desnogues
Laurent
> ---
> target/arm/translate-sve.c | 18 --
> 1 file chang
Hello,
On Mon, Aug 6, 2018 at 1:32 AM, Richard Henderson
wrote:
> If we do not opimize away dup_vec, we must mark its output as changed.
>
> Fixes: 170ba88f45b
> Reported-by: Laurent Desnogues
> Signed-off-by: Richard Henderson
Reviewed-by: Laurent Desnogues
Tested-by: La
Hello Richard,
the case INDEX_op_dup_vec in optimize.c:tcg_optimize is doing a break
when the input arg is not constant instead of jumping to do_default.
The issue can be reproduced by compiling the following SVE code:
.global main
.section .text
main:
mov z2.d, #0
decp
On Wed, Aug 1, 2018 at 2:31 PM, Richard Henderson
wrote:
> Used the wrong temporary in the computation of subtractive overflow.
>
> Reported-by: Laurent Desnogues
> Signed-off-by: Richard Henderson
Reviewed-by: Laurent Desnogues
Tested-by: Laurent Desnogues
Laurent
> --
On Wed, Aug 1, 2018 at 2:31 PM, Richard Henderson
wrote:
> These four patches are minor, reported by Laurent this week.
This fixes the reported issues, thanks!
> If there happens to be an -rc4 release, it would be nice if
> they were included. But if not, no biggie. I suspect that
> other
helper the number of predicate bits to set instead of the number
> of predicate elements to set.
>
> Reported-by: Laurent Desnogues
> Signed-off-by: Richard Henderson
Reviewed-by: Laurent Desnogues
Tested-by: Laurent Desnogues
Laurent
> ---
> target/arm/sve_helper.c| 5 ---
On Wed, Aug 1, 2018 at 2:31 PM, Richard Henderson
wrote:
> The normal vector element is sign-extended before
> comparing with the wide vector element.
>
> Reported-by: Laurent Desnogues
> Signed-off-by: Richard Henderson
Reviewed-by: Laurent Desnogues
Tested-by: Laurent Desno
On Wed, Aug 1, 2018 at 2:31 PM, Richard Henderson
wrote:
> Reported-by: Laurent Desnogues
> Signed-off-by: Richard Henderson
Reviewed-by: Laurent Desnogues
Tested-by: Laurent Desnogues
Laurent
> ---
> target/arm/sve_helper.c | 2 +-
> 1 file changed, 1 insertion
Hello Richard,
there's a typo in sve_movz_d where n[1] is used instead of n[i].
Thanks,
Laurent
Hello,
On Tue, Jul 31, 2018 at 6:36 PM, Richard Henderson
wrote:
> On 07/31/2018 09:52 AM, Laurent Desnogues wrote:
>> Hello Richard,
>>
>> according to SVE specification, whilels/whilele instructions have a
>> special case where if the second operand is the ma
Hello Richard,
according to SVE specification, whilels/whilele instructions have a
special case where if the second operand is the maximum (un)signed
integer then the result is an all-true predicate. The current code in
trans_WHILE doesn't seem to capture that requirement. I'm afraid the
fix
Hello Richard,
the signed overflow computation for 64-bit saturated subtraction in
do_sat_addsub_64 looks wrong: I think the second xor should use t1
instead of t0.
Thanks,
Laurent
Hello Richard,
According to SVE definition, the operands of cmpeq/cmpne SVE
instructions are signed, so I guess the definitions of
sve_cmpeq_ppzw_[bhs] and sve_cmpne_ppzw_[bhs] should use signed types.
The other cmpcc instructions look good.
Thanks,
Laurent
this should apply to DO_LD1_ZPZ_S and DO_LDFF1_ZPZ macros, in
which case you get my review:
Reviewed-by: Laurent Desnogues
Thanks,
Laurent
> ---
>
> Fixes a SIGSEGV within one of these generated helpers,
> exposed by an armclang vectorized code sample.
>
>
> r~
>
Hello,
On Fri, Jun 29, 2018 at 2:15 AM, Richard Henderson
wrote:
> Leave ARM_CP_SVE, removing ARM_CP_FPU; the sve_access_check
> produced by the flag already includes fp_access_check. If
> we also check ARM_CP_FPU the double fp_access_check asserts.
>
> Reported-by: Laurent Desn
On Thu, Jun 7, 2018 at 6:56 AM, Thomas Huth wrote:
> On 06.06.2018 20:56, Markus Armbruster wrote:
>> BALATON Zoltan writes:
>>
>>> Hello,
>>>
>>> Since 12fb0ac05 (char: Remove unwanted crlf conversion) trace output
>>> is printed in stair steps when using -trace and -serial stdio
>>> together.
On Thu, May 24, 2018 at 2:28 PM, Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 23 May 2018 at 06:10, Laurent Desnogues <laurent.desnog...@gmail.com>
> wrote:
>> Some AArch64 tests I had that previously failed on a x86-64 host now pass.
>>
>> Tested-b
Hi,
ZCR system registers are both flagged as ARM_CP_SVE and ARM_CP_FPU,
which results in an assertion failure in fp_access_check due to the
check of these flags in handle_sys:
if ((ri->type & ARM_CP_SVE) && !sve_access_check(s)) {
return;
}
if ((ri->type & ARM_CP_FPU) &&
1 - 100 of 408 matches
Mail list logo
