qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [risu PATCH 0/4] Add support for s390x to RISU


From: Thomas Huth
Subject: Re: [risu PATCH 0/4] Add support for s390x to RISU
Date: Tue, 5 Sep 2023 14:00:51 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0

On 04/09/2023 16.30, Ilya Leoshkevich wrote:
On Mon, 2023-09-04 at 16:00 +0200, Thomas Huth wrote:
  Hi Peter!

Here are some patches that add basic support for s390x to RISU.
It's still quite limited, e.g. no support for load/store memory
operations yet, but the basics with simple 16-bit or 32-bit
instructions work already fine.

(In the long run, we'd need to support instructions with 48-bit
length on s390x, too, since most newer "interesting" instructions
like e.g. vector SIMD instructions are encoded with 48 bit. This
will require modifications to the generic code, too, so I limited
my initial implementation to 16-bit and 32-bit instruction length
support to keep the code self-contained in the s390x architecture
specific files)

What's also interesting about SIMD, is that floating-point instructions
clobber the upper parts of vector registers. I wonder if there is a way
to systematically solve this?#

No clue yet, so far the code does not support the extended vector registers yet (since the weren't part of the information that is provided by the ucontext.h header file).

I guess it should be OK to check only the floating point part for the registers where it overlaps, and only check the full vector register if the register does not overlap ... I don't expect much difference for a vector instruction when it executes with register 0 - 15 compared to when it executes with register 16 - 31, so skipping half of the check for register 0 - 15 shouldn't be too bad.

One other thing - for not-so-near future - is it possible to integrate
this with coverage-based fuzzers? I.e., somehow generate the
instructions based on the coverage signal. Maybe even make sure that
the signal comes from JITed code too. I wanted to try AFLplusplus in
QEMU mode for this purpose (which would ultimately run QEMU in QEMU),
but never found the time.

I don't think this is possible yet, but maybe it's be possible to write a TCG plugin for QEMU to dump the executed instructions into an input file for risu?

 Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]