> Am 16.07.2019 um 14:41 schrieb David Hildenbrand :
>
> How urgent is this? If this can wait, I can polish and send my series I have
> here
> instead, which also implents
> - IEP support
> - access-exception-fetch/store-indication facility
> - ESOP-1, ESOP-2
This is not urgent, I can live with
> Am 16.07.2019 um 15:04 schrieb Cornelia Huck :
>
> On Tue, 16 Jul 2019 14:52:03 +0200
> Ilya Leoshkevich wrote:
>
>>> Am 16.07.2019 um 14:41 schrieb David Hildenbrand :
>>>
>>> How urgent is this? If this can wait, I can polish and send my serie
bit of Region-Third-Table Entry in mmu_translate_region, just
like it's already done for FC bit of Segment-Table Entry in
mmu_translate_segment.
Signed-off-by: Ilya Leoshkevich
Acked-by: Christian Borntraeger
---
target/s390x/cpu.h| 1 +
target/s390x/mmu_helper.c | 8
2 files
On Mon, 2021-06-21 at 09:12 -0400, jonathan.albrecht wrote:
> On 2021-06-21 8:00 am, Ilya Leoshkevich wrote:
> > On Thu, 2021-06-10 at 11:49 +0200, David Hildenbrand wrote:
> > > On 02.06.21 02:22, Ilya Leoshkevich wrote:
> > > > qemu-s390x puts a wrong v
On Thu, 2021-06-10 at 11:49 +0200, David Hildenbrand wrote:
> On 02.06.21 02:22, Ilya Leoshkevich wrote:
> > qemu-s390x puts a wrong value into SIGILL's siginfo_t's psw.addr:
> > it
> > should be a pointer to the instruction following the illegal
> > instruction, but at
On Fri, 2021-06-18 at 09:47 -0400, jonathan.albrecht wrote:
> On 2021-06-01 8:22 pm, Ilya Leoshkevich wrote:
> > Verify that s390x-specific uc_mcontext.psw.addr is reported
> > correctly.
> >
> > Signed-off-by: Ilya Leoshkevich
> > ---
> > tests/tcg/s390x
.c | 19 ++-
> 1 file changed, 10 insertions(+), 9 deletions(-)
I tried this on top of my SIGILL patch to run Maven, it worked without
issues.
Acked-by: Ilya Leoshkevich
Tested-by: Ilya Leoshkevich
Verify that s390x-specific uc_mcontext.psw.addr is reported correctly.
Signed-off-by: Ilya Leoshkevich
---
tests/tcg/s390x/Makefile.target | 1 +
tests/tcg/s390x/signal.c| 165
2 files changed, 166 insertions(+)
create mode 100644 tests/tcg/s390x
-by: Ilya Leoshkevich
Co-developed-by: Ulrich Weigand
---
linux-user/s390x/cpu_loop.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/linux-user/s390x/cpu_loop.c b/linux-user/s390x/cpu_loop.c
index 30568139df..230217feeb 100644
--- a/linux-user/s390x/cpu_loop.c
+++ b/linux-user/s390x
ongnu.org/archive/html/qemu-devel/2021-06/msg05848.html
v4 -> v5: Greatly simplify the fix (Ulrich).
Note: the compare-and-trap SIGFPE issue is being fixed separately.
https://lists.nongnu.org/archive/html/qemu-devel/2021-06/msg05690.html
Ilya Leoshkevich (2):
target/s390x: Fix SIGILL/SI
ongnu.org/archive/html/qemu-devel/2021-06/msg05690.html
Ilya Leoshkevich (2):
target/s390x: Fix SIGILL psw.addr reporting
tests/tcg/s390x: Test SIGILL and SIGSEGV handling
linux-user/s390x/cpu_loop.c | 23 -
target/s390x/excp_helper.c | 71 +++---
target/s390x/i
.
* Protection exception must rewind psw.addr.
* Translation exception must cause a SIGSEGV.
While at it, also fix the handling of addressing and privileged
operation exceptions.
Buglink: https://gitlab.com/qemu-project/qemu/-/issues/319
Signed-off-by: Ilya Leoshkevich
---
linux-user/s390x/cpu_loop.c
Verify that s390x-specific uc_mcontext.psw.addr is reported correctly.
Signed-off-by: Ilya Leoshkevich
---
tests/tcg/s390x/Makefile.target | 1 +
tests/tcg/s390x/signal.c| 165
2 files changed, 166 insertions(+)
create mode 100644 tests/tcg/s390x
tb_gen_code() assumes that tb->size must never be zero, otherwise it
may produce spurious exceptions. For x86_64 this may happen when
creating a translation block for the vsyscall page.
Fix by pretending that vsyscall translation blocks have at least one
instruction.
Signed-off-by: I
This series for the s390-next tree fixes [1]. Patch 1 is the fix, patch
2 is the new test to avoid similar regressions in the future.
[1] https://lists.nongnu.org/archive/html/qemu-devel/2021-05/msg02962.html
Ilya Leoshkevich (2):
target/i386: Make sure that vsyscall's tb->size != 0
te
Having a small test will prevent trivial regressions in the future.
Signed-off-by: Ilya Leoshkevich
---
tests/tcg/x86_64/Makefile.target | 6 +-
tests/tcg/x86_64/vsyscall.c | 11 +++
2 files changed, 16 insertions(+), 1 deletion(-)
create mode 100644 tests/tcg/x86_64
Having a small test will prevent trivial regressions in the future.
Signed-off-by: Ilya Leoshkevich
---
tests/tcg/x86_64/Makefile.target | 6 +-
tests/tcg/x86_64/vsyscall.c | 12
2 files changed, 17 insertions(+), 1 deletion(-)
create mode 100644 tests/tcg/x86_64
tb_gen_code() assumes that tb->size must never be zero, otherwise it
may produce spurious exceptions. For x86_64 this may happen when
creating a translation block for the vsyscall page.
Fix by pretending that vsyscall translation blocks have at least one
instruction.
Signed-off-by: I
out the patch too).
Ilya Leoshkevich (2):
target/i386: Make sure that vsyscall's tb->size != 0
tests/tcg/x86_64: add vsyscall smoke test
target/i386/tcg/translate.c | 1 +
tests/tcg/x86_64/Makefile.target | 6 +-
tests/tcg/x86_64/vsyscall.c | 12
3 files chang
On Mon, 2021-05-17 at 14:52 +0200, Cornelia Huck wrote:
> On Wed, 12 May 2021 06:02:50 +0200
> Ilya Leoshkevich wrote:
>
> > Having a small test will prevent trivial regressions in the future.
> >
> > Signed-off-by: Ilya Leoshkevich
> > ---
> >
Verify that s390x-specific uc_mcontext.psw.addr is reported correctly.
Signed-off-by: Ilya Leoshkevich
---
tests/tcg/s390x/Makefile.target | 1 +
tests/tcg/s390x/sigill.c| 41 +
2 files changed, 42 insertions(+)
create mode 100644 tests/tcg/s390x
adds a test.
Ilya Leoshkevich (2):
target/s390x: Fix SIGILL psw.addr reporting
tests/tcg/s390x: Test SIGILL handling
linux-user/s390x/cpu_loop.c | 6 ++-
target/s390x/excp_helper.c | 69 ++---
target/s390x/internal.h | 1 +
tests/tcg/s390x
that raised the exception.
Buglink: https://bugs.launchpad.net/qemu/+bug/1920913
Signed-off-by: Ilya Leoshkevich
---
linux-user/s390x/cpu_loop.c | 6 +++-
target/s390x/excp_helper.c | 69 -
target/s390x/internal.h | 1 +
3 files changed, 43 insertions(+), 33
On Fri, 2021-05-21 at 09:42 +0200, David Hildenbrand wrote:
> On 21.05.21 05:01, Ilya Leoshkevich wrote:
> > qemu-s390x puts a wrong value into SIGILL's siginfo_t's psw.addr:
> > it
> > should be a pointer to the instruction following the illegal
> > instruction, but at
On Fri, 2021-05-21 at 09:54 +0200, David Hildenbrand wrote:
> On 21.05.21 05:01, Ilya Leoshkevich wrote:
> > Verify that s390x-specific uc_mcontext.psw.addr is reported
> > correctly.
> >
> > Signed-off-by: Ilya Leoshkevich
> > ---
> > tests/tcg/s390x
Verify that s390x-specific uc_mcontext.psw.addr is reported correctly.
Signed-off-by: Ilya Leoshkevich
---
tests/tcg/s390x/Makefile.target | 1 +
tests/tcg/s390x/sigill.c| 52 +
2 files changed, 53 insertions(+)
create mode 100644 tests/tcg/s390x
adds a test.
v1: https://lists.nongnu.org/archive/html/qemu-devel/2021-05/msg06592.html
v1 -> v2: Use a better buglink (Cornelia), simplify the inline asm
magic in the test and add an explanation (David).
Ilya Leoshkevich (2):
target/s390x: Fix SIGILL psw.addr reporting
tests/tcg/s3
that raised the exception.
Buglink: https://gitlab.com/qemu-project/qemu/-/issues/319
Signed-off-by: Ilya Leoshkevich
Reviewed-by: David Hildenbrand
---
linux-user/s390x/cpu_loop.c | 6 +++-
target/s390x/excp_helper.c | 69 -
target/s390x/internal.h | 1
.
* Protection exception must rewind psw.addr.
* Translation exception must cause a SIGSEGV.
While at it, also fix the handling of addressing and privileged
operation exceptions.
Buglink: https://gitlab.com/qemu-project/qemu/-/issues/319
Signed-off-by: Ilya Leoshkevich
---
linux-user/s390x/cpu_loop.c
gt; v3: Fix SIGSEGV handling (found when trying to run valgrind under
qemu-user).
Ilya Leoshkevich (2):
target/s390x: Fix SIGILL psw.addr reporting
tests/tcg/s390x: Test SIGILL and SIGSEGV handling
linux-user/s390x/cpu_loop.c | 23 -
target/s390x/excp_helper.c
Verify that s390x-specific uc_mcontext.psw.addr is reported correctly.
Signed-off-by: Ilya Leoshkevich
---
tests/tcg/s390x/Makefile.target | 1 +
tests/tcg/s390x/signal.c| 163
2 files changed, 164 insertions(+)
create mode 100644 tests/tcg/s390x
On Fri, 2021-05-21 at 13:19 +0200, Ilya Leoshkevich wrote:
> qemu-s390x puts a wrong value into SIGILL's siginfo_t's psw.addr: it
> should be a pointer to the instruction following the illegal
> instruction, but at the moment it is a pointer to the illegal
> instruction itself. This br
valgrind fails to start under linux-user, one of the reasons being that
it tries to query all the sigactions, which qemu (unlike the real
kernel) doesn't allow for SIGKILL/SIGSTOP.
Patch 1 lifts this restriction, patch 2 adds a test.
Ilya Leoshkevich (2):
linux-user: Let sigaction query
The kernel allows doing this, so let's allow this in qemu as well.
Valgrind relies on this.
Signed-off-by: Ilya Leoshkevich
---
linux-user/signal.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 9016896dcd..bc3431708f
test_socket hangs randomly in connect(), especially when run without
qemu. Apparently the reason is that linux started treating backlog
value of 0 literally instead of rounding it up since v4.4 (commit
ef547f2ac16b).
So set it to 1 instead.
Signed-off-by: Ilya Leoshkevich
---
tests/tcg
Verify that querying is allowed, but making changes isn't.
Signed-off-by: Ilya Leoshkevich
---
tests/tcg/multiarch/linux-test.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/tests/tcg/multiarch/linux-test.c b/tests/tcg/multiarch/linux-test.c
index ce033c21c7..cd9d8159bc 100644
On Tue, 2021-06-01 at 14:38 +0200, Ilya Leoshkevich wrote:
> On Fri, 2021-05-21 at 13:19 +0200, Ilya Leoshkevich wrote:
> > qemu-s390x puts a wrong value into SIGILL's siginfo_t's psw.addr: it
> > should be a pointer to the instruction following the illegal
> > instructi
On Mon, 2021-07-12 at 10:59 -0400, jonathan.albrecht wrote:
> On 2021-07-02 8:01 am, Laurent Vivier wrote:
> > Le 02/07/2021 à 12:34, Cornelia Huck a écrit :
> > > On Wed, Jun 23 2021, Ilya Leoshkevich wrote:
> > >
> > >
> > > What's the st
On Mon, 2021-07-05 at 21:18 +0200, David Hildenbrand wrote:
> On 05.07.21 19:24, Ilya Leoshkevich wrote:
> > On Mon, 2021-07-05 at 11:36 +0200, David Hildenbrand wrote:
> > > On 23.06.21 04:32, Ilya Leoshkevich wrote:
> > > > For SIGILL, SIGFPE and SI
/319
Signed-off-by: Ilya Leoshkevich
Co-developed-by: Ulrich Weigand
---
linux-user/s390x/cpu_loop.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/linux-user/s390x/cpu_loop.c b/linux-user/s390x/cpu_loop.c
index 30568139df..6e7dfb290a 100644
--- a/linux-user/s390x
On Mon, 2021-07-05 at 11:36 +0200, David Hildenbrand wrote:
> On 23.06.21 04:32, Ilya Leoshkevich wrote:
> > For SIGILL, SIGFPE and SIGTRAP the PSW must point after the
> > instruction, and at the instruction for other signals. Currently
> > under
> > qemu-user it alway
Verify that s390x-specific uc_mcontext.psw.addr is reported correctly
and that signal handling interacts properly with debugging.
Signed-off-by: Ilya Leoshkevich
---
tests/tcg/s390x/Makefile.target | 18 +-
tests/tcg/s390x/gdbstub/test-signals-s390x.py | 76
tests/tcg
ists.nongnu.org/archive/html/qemu-devel/2021-06/msg05690.html
Ilya Leoshkevich (2):
target/s390x: Fix SIGILL and SIGFPE psw.addr reporting
tests/tcg/s390x: Test SIGILL and SIGSEGV handling
linux-user/s390x/cpu_loop.c | 12 +-
tests/tcg/s390x/Makefile.target
Public bug reported:
QEMU version:
1214d55d1c (HEAD, origin/master, origin/HEAD) Merge remote-tracking branch
'remotes/nvme/tags/nvme-next-pull-request' into staging
Consider the following little program:
$ cat 1.c
#include
int main() {
int mem = 0x12345678;
register long rax asm("rax") =
On Wed, 2021-04-14 at 18:23 -0700, Max Filippov wrote:
> On Wed, Apr 14, 2021 at 12:43 PM Richard Henderson
> wrote:
> >
> > On 4/14/21 11:03 AM, Max Filippov wrote:
> > > On Wed, Apr 14, 2021 at 9:51 AM Ilya Leoshkevich <
> > > i...@linux.ibm.com>
in order to fix
https://gitlab.com/cohuck/qemu/-/jobs/1178409450
v3: https://lists.nongnu.org/archive/html/qemu-devel/2021-04/msg02332.html
v3 -> v4: Add the xtensa patch in order to fix
https://gitlab.com/cohuck/qemu/-/jobs/1178409540
Ilya Leoshkevich (4):
target/s390x: Fix
ion handler.
Fix by pretending that the size of the respective translation block is
1 in all these cases.
Signed-off-by: Ilya Leoshkevich
---
target/xtensa/translate.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/target/xtensa/translate.c b/target/xtensa/translate.c
index 0ae4efc
If arch-specific code generates a translation block of size 0,
tb_gen_code() may generate a spurious exception. Add an assertion in
order to catch such situations early.
Signed-off-by: Ilya Leoshkevich
Reviewed-by: David Hildenbrand
---
accel/tcg/translate-all.c | 1 +
1 file changed, 1
bytes that have been looked at must count towards tb->size.
So adjust s390x's translate_one() to act this way for both illegal
instructions and instructions that are known to generate exceptions.
Signed-off-by: Ilya Leoshkevich
Reviewed-by: David Hildenbrand
---
target/s390x/transla
tb_gen_code() assumes that tb->size must never be zero, otherwise it
may produce spurious exceptions. For ARM this may happen when creating
a translation block for the commpage.
Fix by pretending that commpage translation blocks have at least one
instruction.
Signed-off-by: Ilya Leoshkev
On Thu, 2021-04-15 at 17:39 +0200, Cornelia Huck wrote:
> On Thu, 15 Apr 2021 15:03:01 +0200
> Ilya Leoshkevich wrote:
>
> > If arch-specific code generates a translation block of size 0,
> > tb_gen_code() may generate a spurious exception.
> >
> > Fix s390x (p
t need to link pages in this case.
Signed-off-by: Ilya Leoshkevich
---
accel/tcg/translate-all.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
index ba6ab09790..77043b98c4 100644
--- a/accel/tcg/translate-all.c
+++ b
On Wed, 2021-04-14 at 11:19 +0200, Ilya Leoshkevich wrote:
> On Wed, 2021-04-14 at 10:38 +0200, Cornelia Huck wrote:
> > On Tue, 13 Apr 2021 18:52:57 +0200
> > Ilya Leoshkevich wrote:
> >
> > > Hitting an uretprobe in a s390x TCG guest causes
On Wed, 2021-04-14 at 10:38 +0200, Cornelia Huck wrote:
> On Tue, 13 Apr 2021 18:52:57 +0200
> Ilya Leoshkevich wrote:
>
> > Hitting an uretprobe in a s390x TCG guest causes a SIGSEGV. What
> > happens is:
> >
> > * uretprobe maps a userspace page cont
.
Signed-off-by: Ilya Leoshkevich
---
v1: https://lists.nongnu.org/archive/html/qemu-devel/2021-04/msg02037.html
v1 -> v2: Fix target/s390x instead of trying to tolerate tb->size == 0
in tb_gen_code().
accel/tcg/translate-all.c | 1 +
target/s390x/translate.c | 16 ++
https://gitlab.com/cohuck/qemu/-/jobs/1178409450
Ilya Leoshkevich (3):
target/s390x: Fix translation exception on illegal instruction
target/arm: Make sure that commpage's tb->size != 0
accel/tcg: Assert that tb->size != 0 after translation
accel/tcg/translate-all.c | 1 +
target/
tb_gen_code() assumes that tb->size must never be zero, otherwise it
may produce spurious exceptions. For ARM this may happen when creating
a translation block for the commpage.
Fix by pretending that commpage translation blocks have at least one
instruction.
Signed-off-by: Ilya Leoshkev
If arch-specific code generates a translation block of size 0,
tb_gen_code() may generate a spurious exception. Add an assertion in
order to catch such situations early.
Signed-off-by: Ilya Leoshkevich
---
accel/tcg/translate-all.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/accel/tcg
bytes that have been looked at must count towards tb->size.
So adjust s390x's translate_one() to act this way for both illegal
instructions and instructions that are known to generate exceptions.
Signed-off-by: Ilya Leoshkevich
---
target/s390x/translate.c | 16 +++-
1 file ch
and
env_strings instead of arg_start and arg_end.
Signed-off-by: Ilya Leoshkevich
---
linux-user/elfload.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 4e45bd1539..cffcebfe45 100644
--- a/linux-user/elfload.c
+++ b/linux-user
.
Signed-off-by: Ilya Leoshkevich
---
linux-user/elfload.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index c6731013fd..4e45bd1539 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -1385,6 +1385,39
On Wed, 2021-04-14 at 16:48 +0200, David Hildenbrand wrote:
> On 14.04.21 15:41, Ilya Leoshkevich wrote:
> > If arch-specific code generates a translation block of size 0,
> > tb_gen_code() may generate a spurious exception. Add an assertion
> > in
> > order to
ion handler.
Fix by pretending that the size of the respective translation block is
1 in all these cases.
Signed-off-by: Ilya Leoshkevich
Tested-by: Max Filippov
Acked-by: Max Filippov
---
target/xtensa/translate.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/target/xtensa/translate.
On Fri, 2021-04-16 at 15:10 +0100, Peter Maydell wrote:
> On Thu, 15 Apr 2021 at 14:03, Ilya Leoshkevich
> wrote:
> >
> > tb_gen_code() assumes that tb->size must never be zero, otherwise
> > it
> > may produce spurious exceptions. For ARM this may happen wh
tb_gen_code() assumes that tb->size must never be zero, otherwise it
may produce spurious exceptions. For ARM this may happen when creating
a translation block for the commpage.
Fix by pretending that commpage translation blocks have at least one
instruction.
Signed-off-by: Ilya Leoshkev
bytes that have been looked at must count towards tb->size.
So adjust s390x's translate_one() to act this way for both illegal
instructions and instructions that are known to generate exceptions.
Signed-off-by: Ilya Leoshkevich
Reviewed-by: David Hildenbrand
---
target/s390x/transla
l/qemu-devel/2021-04/msg02592.html
v4 -> v5: Handle thumb: the following C code triggers the assertion:
typedef void (*funcptr)(void);
int main() { funcptr f = (funcptr)0xffff0001; f(); }
Ilya Leoshkevich (4):
target/s390x: Fix translation exception on illegal instruction
t
If arch-specific code generates a translation block of size 0,
tb_gen_code() may generate a spurious exception. Add an assertion in
order to catch such situations early.
Signed-off-by: Ilya Leoshkevich
Reviewed-by: David Hildenbrand
---
accel/tcg/translate-all.c | 1 +
1 file changed, 1
On Wed, 2021-08-04 at 00:16 +0200, Ilya Leoshkevich wrote:
> x86_64 dotnet/runtime uses cmpxchg for code patching. When running it
> under s390x qemu-linux user, cpu_signal_handler() does not recognize
> this as a write and does not restore PAGE_WRITE cleared by
> tb_page_add(),
setup_rt_frame() passes siginfo and ucontext host addresses to guest
signal handlers, causing problems when e.g. emulating x86_64 on s390x.
Signed-off-by: Ilya Leoshkevich
---
linux-user/i386/signal.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/linux-user/i386
Core dumps from emulating x86_64 on big-endian hosts contain incorrect
register values.
Signed-off-by: Ilya Leoshkevich
---
linux-user/elfload.c | 88 ++--
1 file changed, 44 insertions(+), 44 deletions(-)
diff --git a/linux-user/elfload.c b/linux-user
://lists.nongnu.org/archive/html/qemu-devel/2021-08/msg00644.html
Signed-off-by: Ilya Leoshkevich
---
v1: https://lists.nongnu.org/archive/html/qemu-devel/2021-08/msg00712.html
v1 -> v2: Clear PAGE_WRITE for the initial page and then on each read
that crosses a page boundary (Rich
On Thu, 2021-08-05 at 06:59 -1000, Richard Henderson wrote:
> On 8/5/21 12:56 AM, Ilya Leoshkevich wrote:
> > On Wed, 2021-08-04 at 14:30 -1000, Richard Henderson wrote:
> > > I think that the translator_ld*_swap functions should be moved
> > > out of
> > > incl
.
[1] https://lists.nongnu.org/archive/html/qemu-devel/2021-08/msg00644.html
Signed-off-by: Ilya Leoshkevich
---
v2: https://lists.nongnu.org/archive/html/qemu-devel/2021-08/msg00819.html
v2 -> v3: Move translator_ld*_swap() functions from translator.h into
translator.c for a bet
Hello,
I'm trying to run a .NET app with qemu-x86_64 on a s390x host. With a
few fixes posted earlier it works for a while and then crashes like
this:
(gdb) x/8i $pc-6
0x3f8ab23ef8:jmpq 0x3f87d2c5e0
0x3f8ab23efd:pop%rdi
=> 0x3f8ab23efe:sub(%rdx),%al
talking about user-only, where translation is
always serial.
stsquad: the link from january is a system-mode bug of the same kind,
where, yes, we need to hold the page lock or something.
rth: ahh yes because we don't have zoned translation caches...
Ilya Leoshkevich (1):
accel/tcg: Clear
/2021-08/msg00644.html
Signed-off-by: Ilya Leoshkevich
---
accel/tcg/translate-all.c| 59 +---
accel/tcg/translator.c | 26 ++--
include/exec/translate-all.h | 1 +
3 files changed, 59 insertions(+), 27 deletions(-)
diff --git a/accel/tcg
Verify that s390x-specific uc_mcontext.psw.addr is reported correctly
and that signal handling interacts properly with debugging.
Signed-off-by: Ilya Leoshkevich
---
v7: https://lists.nongnu.org/archive/html/qemu-devel/2021-08/msg00463.html
v7 -> v8: Another rebase needed due to the confl
x86_64 dotnet/runtime uses cmpxchg for code patching. When running it
under s390x qemu-linux user, cpu_signal_handler() does not recognize
this as a write and does not restore PAGE_WRITE cleared by
tb_page_add(), incorrectly forwarding the signal to the guest code.
Signed-off-by: Ilya Leoshkevich
On Wed, 2021-08-04 at 14:30 -1000, Richard Henderson wrote:
> On 8/4/21 12:46 PM, Ilya Leoshkevich wrote:
> > translate_insn() implementations fetch instruction bytes piecemeal,
> > which can cause qemu-user to generate inconsistent translations if
> > another thread modifies
x86_64 dotnet/runtime uses cmpxchg for code patching. When running it
under s390x qemu-linux user, cpu_signal_handler() does not recognize
this as a write and does not restore PAGE_WRITE cleared by
tb_page_add(), incorrectly forwarding the signal to the guest code.
Signed-off-by: Ilya Leoshkevich
Verify that s390x-specific uc_mcontext.psw.addr is reported correctly
and that signal handling interacts properly with debugging.
Signed-off-by: Ilya Leoshkevich
---
v6: https://lists.nongnu.org/archive/html/qemu-devel/2021-07/msg00873.html
v6 -> v7: Rebased.
tests/tcg/s390x/Makefile.tar
On Thu, 2021-08-05 at 11:37 +0200, David Hildenbrand wrote:
> On 05.08.21 00:51, Ilya Leoshkevich wrote:
> > Verify that s390x-specific uc_mcontext.psw.addr is reported
> > correctly
> > and that signal handling interacts properly with debugging.
> >
> >
On Fri, 2021-08-06 at 07:25 +0200, Thomas Huth wrote:
> On 05/08/2021 00.51, Ilya Leoshkevich wrote:
> > Verify that s390x-specific uc_mcontext.psw.addr is reported
> > correctly
> > and that signal handling interacts properly with debugging.
> >
> >
On Mon, 2021-07-05 at 23:04 +0200, Ilya Leoshkevich wrote:
> Verify that s390x-specific uc_mcontext.psw.addr is reported correctly
> and that signal handling interacts properly with debugging.
>
> Signed-off-by: Ilya Leoshkevich
> ---
> tests/tcg/s390x/Makefile.target
On Tue, 2021-06-01 at 16:20 +0200, Ilya Leoshkevich wrote:
> test_socket hangs randomly in connect(), especially when run without
> qemu. Apparently the reason is that linux started treating backlog
> value of 0 literally instead of rounding it up since v4.4 (commit
> ef547f2ac16b).
Add a test for each shift instruction in order to to prevent
regressions.
Signed-off-by: Ilya Leoshkevich
---
tests/tcg/s390x/Makefile.target | 1 +
tests/tcg/s390x/shift.c | 258
2 files changed, 259 insertions(+)
create mode 100644 tests/tcg/s390x
INGLE")
Signed-off-by: Ilya Leoshkevich
---
target/s390x/tcg/cc_helper.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/target/s390x/tcg/cc_helper.c b/target/s390x/tcg/cc_helper.c
index c2c96c3a3c..b6acffa3e8 100644
--- a/target/s390x/tcg/cc_helper.c
+++ b/target
David Hildenbrand noticed that sign bit index for SLDA is wrong: since
SLDA operates on 64-bit values, it should be 63, not 31.
Fixes: a79ba3398a0a ("target-s390: Convert SHIFT DOUBLE")
Signed-off-by: Ilya Leoshkevich
---
target/s390x/tcg/insn-data.def | 2 +-
1 file changed, 1 inser
est.
Split the series.
Ilya Leoshkevich (5):
target/s390x: Fix SLDA sign bit index
target/s390x: Fix SRDA CC calculation
target/s390x: Fix cc_calc_sla_64() missing overflows
target/s390x: Fix shifting 32-bit values for more than 31 bits
tests/tcg/s390x: Test shift instructions
target/s3
On Tue, 2022-01-11 at 15:22 +0100, David Hildenbrand wrote:
> On 10.01.22 19:59, Ilya Leoshkevich wrote:
> > Both 32- and 64-bit shifts use lowest 6 address bits. The current
> > code
> > special-cases 32-bit shifts to use only 5 bits, which is not
> > correct.
> >
and sh64 and adapting cc_calc_sla_32() to shift
values greater than 31.
Fixes: cbe24bfa91d2 ("target-s390: Convert SHIFT, ROTATE SINGLE")
Signed-off-by: Ilya Leoshkevich
---
target/s390x/tcg/cc_helper.c | 32 +-
target/s390x/tcg/insn-dat
SRDA uses r1_D32 for binding the first operand and s64 for setting CC.
cout_s64() relies on o->out being the shift result, however,
wout_r1_D32() clobbers it.
Fix by using a temporary.
Fixes: a79ba3398a0a ("target-s390: Convert SHIFT DOUBLE")
Signed-off-by: Ilya Leoshkevich
---
SRDA uses r1_D32 for binding the first operand and s64 for setting CC.
cout_s64() relies on o->out being the shift result, however,
wout_r1_D32() clobbers it.
Fix by using a temporary.
Fixes: a79ba3398a0a ("target-s390: Convert SHIFT DOUBLE")
Signed-off-by: Ilya Leoshkevich
Revie
On Wed, 2022-01-12 at 09:59 +0100, David Hildenbrand wrote:
> On 12.01.22 05:39, Ilya Leoshkevich wrote:
> > An overflow occurs for SLAG when at least one shifted bit is not
> > equal
> > to sign bit. Therefore, we need to check that `shift + 1` bits are
> > neither all
series.
Ilya Leoshkevich (5):
target/s390x: Fix SLDA sign bit index
target/s390x: Fix SRDA CC calculation
target/s390x: Fix cc_calc_sla_64() missing overflows
target/s390x: Fix shifting 32-bit values for more than 31 bits
tests/tcg/s390x: Test shift instructions
target/s390x/cpu-
SLDA operates on 64-bit values, so its sign bit index should be 63,
not 31.
Fixes: a79ba3398a0a ("target-s390: Convert SHIFT DOUBLE")
Reported-by: David Hildenbrand
Signed-off-by: Ilya Leoshkevich
Reviewed-by: David Hildenbrand
---
target/s390x/tcg/insn-data.def | 2 +-
1 file
INGLE")
Co-developed-by: David Hildenbrand
Signed-off-by: Ilya Leoshkevich
---
target/s390x/tcg/cc_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/s390x/tcg/cc_helper.c b/target/s390x/tcg/cc_helper.c
index c2c96c3a3c..c9b7b0e8c6 100644
--- a/target
SRDA uses r1_D32 for binding the first operand and s64 for setting CC.
cout_s64() relies on o->out being the shift result, however,
wout_r1_D32() clobbers it.
Fix by using a temporary.
Fixes: a79ba3398a0a ("target-s390: Convert SHIFT DOUBLE")
Signed-off-by: Ilya Leoshkevich
---
bit index.
Inline help_l2_shift().
Fix wout_r1_D32().
Add all shift instructions to the test.
Split the series.
Ilya Leoshkevich (5):
target/s390x: Fix SLDA sign bit index
target/s390x: Fix SRDA CC calculation
target/s390x: Fix cc_calc_sla_64() missing
1 - 100 of 957 matches
Mail list logo
