From: Giuseppe Musacchio
The implicit cast from abi_long to size_t may introduce an intermediate
unwanted sign-extension of the value for 32bit targets running on 64bit
hosts.
Signed-off-by: Giuseppe Musacchio
---
linux-user/syscall.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
di
From: Giuseppe Musacchio
An unwanted sign-extension is currently making the host kernel return EOVERFLOW
when calling copy_file_range with a count of 0x, despite the host being
a 64bit platform.
The fix is only affecting 32bit targets on 64bit hosts, it's a no-op when the
target bitness
From: Giuseppe Musacchio
Signed-off-by: Giuseppe Musacchio
---
linux-user/strace.list | 3 +++
1 file changed, 3 insertions(+)
diff --git a/linux-user/strace.list b/linux-user/strace.list
index 084048ab96..b81f9964e3 100644
--- a/linux-user/strace.list
+++ b/linux-user/strace.list
@@ -1665,3 +
Since we always perform a comparison between the two operands avoid
checking for NaN unless the result states they're unordered.
Suggested-by: Richard Henderson
Signed-off-by: Giuseppe Musacchio
Reviewed-by: Richard Henderson
---
target/ppc/fpu_helper.c | 80 +--
Suggested-by: Richard Henderson
Signed-off-by: Giuseppe Musacchio
Reviewed-by: Richard Henderson
---
target/ppc/fpu_helper.c | 222 ++--
1 file changed, 120 insertions(+), 102 deletions(-)
diff --git a/target/ppc/fpu_helper.c b/target/ppc/fpu_helper.c
index
Fix a couple of problems found in the emulation of f64/f128 comparisons plus
some minimal self-contained commits to clean-up some code.
Giuseppe Musacchio (4):
ppc/translate: Fix unordered f64/f128 comparisons
ppc/translate: Turn the helper macros into functions
ppc/translate: Delay NaN chec
According to the PowerISA v3.1 reference, Table 68 "Actions for xscmpudp
- Part 1: Compare Unordered", whenever one of the two operands is a NaN
the SO bit is set while the other three bits are cleared.
Apply the same change to xscmpuqp.
The respective ordered counterparts are unaffected.
Signed
The PowerISA reference states that the comparison operators update the
FPCC, CR and FPSCR and, if VE=1, jump to the exception handler.
Moving the exception-triggering code after the CC update sequence solves
the problem.
Signed-off-by: Giuseppe Musacchio
Reviewed-by: Richard Henderson
---
targ
The PowerISA reference states that the comparison operators update the
FPCC, CR and FPSCR and, if VE=1, jump to the exception handler.
Moving the exception-triggering code after the CC update sequence solves
the problem.
Signed-off-by: Giuseppe Musacchio
---
target/ppc/fpu_helper.c | 28 +++
Suggested-by: Richard Henderson
Signed-off-by: Giuseppe Musacchio
---
target/ppc/fpu_helper.c | 220 +---
1 file changed, 118 insertions(+), 102 deletions(-)
diff --git a/target/ppc/fpu_helper.c b/target/ppc/fpu_helper.c
index b07ff66375..c74c080c17 100644
--
According to the PowerISA v3.1 reference, Table 68 "Actions for xscmpudp
- Part 1: Compare Unordered", whenever one of the two operands is a NaN
the SO bit is set while the other three bits are cleared.
Apply the same change to xscmpuqp.
The respective ordered counterparts are unaffected.
Signed
Since we always perform a comparison between the two operands avoid
checking for NaN unless the result states they're unordered.
Suggested-by: Richard Henderson
Signed-off-by: Giuseppe Musacchio
---
target/ppc/fpu_helper.c | 82 +
1 file changed, 42 inser
Fix a couple of problems found in the emulation of f64/f128 comparisons plus
some minimal self-contained commits to clean-up some code.
Is it too late to ask for inclusion in the upcoming release?
Giuseppe Musacchio (4):
ppc/translate: Fix unordered f64/f128 comparisons
ppc/translate: Turn th
Is there any chance for this patch series to be merged for 5.2?
On 09/11/20 18:39, Richard Henderson wrote:
> On 11/9/20 1:17 AM, LemonBoy wrote:
>> Implement the "Load VSX Vector Word & Splat Indexed" opcode, introduced
>> in Power ISA v3.0.
>>
>> Bugl
On 10/11/20 04:24, Richard Henderson wrote:
> On 11/9/20 2:21 AM, LemonBoy wrote:
>> According to the PowerISA v3.1 reference, Table 68 "Actions for xscmpudp
>> - Part 1: Compare Unordered", whenever one of the two operands is a NaN
>> the SO bit is set while t
Hello Laurent,
you probably want to also apply my patch for stack_t definitions [1] that
was mentioned in Peter Maydell's cover letter for the patch series.
[1] https://patchew.org/QEMU/e9d47692-ee92-009f-6007-0abc3f502...@gmail.com/
On 10/11/20 07:53, Laurent Vivier wrote:
> Le 05/11/2020 à 22:2
According to the PowerISA v3.1 reference, Table 68 "Actions for xscmpudp
- Part 1: Compare Unordered", whenever one of the two operands is a NaN
the SO bit is set while the other three bits are cleared.
Apply the same change to xscmpuqp.
The respective ordered counterparts are unaffected.
Signed
Make the implementation match the lxvwsx one.
The code is now shorter smaller and potentially faster as the
translation will use the host SIMD capabilities if available.
No functional change.
Signed-off-by: Giuseppe Musacchio
---
target/ppc/translate/vsx-impl.c.inc | 46 ++--
Implement the "Load VSX Vector Word & Splat Indexed" opcode, introduced
in Power ISA v3.0.
Buglink: https://bugs.launchpad.net/qemu/+bug/1793608
Signed-off-by: Giuseppe Musacchio
---
target/ppc/translate/vsx-impl.c.inc | 30 +
target/ppc/translate/vsx-ops.c.inc | 1
Some platforms used the wrong definition of stack_t where the flags and
size fields were swapped or where the flags field had type ulong instead
of int.
Due to the presence of padding space in the structure and the prevalence
of little-endian machines this problem went unnoticed for a long time.
On 05/11/20 16:16, Peter Maydell wrote:
> On Thu, 5 Nov 2020 at 14:55, LemonBoy wrote:
>>
>> From 914c30863b45d6fcd3e2fc83929bcac546be1555 Mon Sep 17 00:00:00 2001
>> From: LemonBoy
>> Date: Thu, 5 Nov 2020 15:48:24 +0100
>> Subject: [PATCH] linux-user: Correct
>From 914c30863b45d6fcd3e2fc83929bcac546be1555 Mon Sep 17 00:00:00 2001
From: LemonBoy
Date: Thu, 5 Nov 2020 15:48:24 +0100
Subject: [PATCH] linux-user: Correct definition of stack_t
Some platforms used the wrong definition of stack_t where the flags and
size fields were swapped or where
>From 894bb5172705e46a3a04c93b4962c0f0cafee814 Mon Sep 17 00:00:00 2001
From: Giuseppe Musacchio
Date: Fri, 17 Apr 2020 17:25:07 +0200
Subject: [PATCH] linux-user: Prevent crash in epoll_ctl
The `event` parameter is ignored by the kernel if `op` is EPOLL_CTL_DEL,
do the same and avoid returning E
Ping, I forgot to CC the SPARC mantainers in the previous mail.
On 10/04/20 23:14, LemonBoy wrote:
> From 11d0cfe58d12e0f191b435ade88622cfceb2098a Mon Sep 17 00:00:00 2001
> From: LemonBoy
> Date: Fri, 10 Apr 2020 22:55:26 +0200
> Subject: [PATCH] linux-user/sparc64: Translate f
>From 11d0cfe58d12e0f191b435ade88622cfceb2098a Mon Sep 17 00:00:00 2001
From: LemonBoy
Date: Fri, 10 Apr 2020 22:55:26 +0200
Subject: [PATCH] linux-user/sparc64: Translate flushw opcode
The ifdef logic should unconditionally compile in the `xop == 0x2b` case
when targeting sparc64.
Fix
The CPU loop tagged all the queued signals as QEMU_SI_KILL while it was
filling the `_sigfault` part of `siginfo`: this caused QEMU to copy the
wrong fields over to the userspace program.
Make sure the fault address recorded by the MMU is is stored in the CPU
environment structure.
In case of mem
26 matches
Mail list logo
