qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Cc: "open list:RISC-V" <qemu-riscv@nongnu.org>,
	Richard Henderson <richard.henderson@linaro.org>,
	Alistair Francis <Alistair.Francis@wdc.com>,
	qemu-devel@nongnu.org
Subject: Re: Question about TCG backend correctness
Date: Mon, 17 Oct 2022 11:30:51 +0100	[thread overview]
Message-ID: <87lepeeno0.fsf@linaro.org> (raw)
In-Reply-To: <4672400c-0084-3bf3-a596-7a42115301f0@linux.alibaba.com>


LIU Zhiwei <zhiwei_liu@linux.alibaba.com> writes:

> Hi folks,
>
>     For TCG front end, we can test it with tools, such as RISU. But I
> don't know if  there are some tools that can help
> to verify the correctness of a TCG backend.
>
>     Can someone share the tools or the experience to debug RISC-V
> backend?  Thanks very much.

It's mostly down to inspection or debugging failures. Sometimes you can
attempt to shake out bugs by running a stacked QEMU. e.g.

   qemu-system-aarch64 on x86 host
   qemu-system-aarch64 on qemu-system-riscv64 on x86 host

and see if the two aarch64 guests run the same. This of course gets very
tricky running full OS kernels because as soon as time and async
interrupts get involved you will get divergence anyway. This would work
best with simple straight line test cases (e.g. check-tcg test cases).

I've long wanted to have the ability to have TCG unit tests where a
virtual processor could be defined for the purpose of directly
exercising TCG. This would be mainly to check tcg_optimize() works
correctly but no doubt could be extended to verify the eventual backend
output. The problem with implementing such an approach has been the
amount of boilerplate needed to define a simple frontend. Maybe this
will get simpler as we slowly move to a single binary build but there is
still quite of lot of things TCG needs to know about the guest it is
emulating.

If you would like to attempt improve the testing situation for TCG and its
backend I'm fully supportive.

-- 
Alex Bennée


  reply	other threads:[~2022-10-17 10:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-17  9:47 Question about TCG backend correctness LIU Zhiwei
2022-10-17 10:30 ` Alex Bennée [this message]
2022-10-17 15:27   ` LIU Zhiwei
2022-10-18  5:22     ` Richard Henderson
2022-10-18  9:22       ` Alex Bennée
2022-10-18 23:03         ` Richard Henderson
2022-10-19 11:59       ` LIU Zhiwei
2022-10-19 13:46         ` Alex Bennée

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lepeeno0.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=Alistair.Francis@wdc.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-riscv@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=zhiwei_liu@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).