qemu-riscv
[Top][All Lists]
Advanced

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

Re: Question about TCG backend correctness


From: LIU Zhiwei
Subject: Re: Question about TCG backend correctness
Date: Mon, 17 Oct 2022 23:27:45 +0800
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.3


On 2022/10/17 18:30, Alex Bennée wrote:
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.
Agree.
  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.
We currently depend on the guest behaviors to test the correctness of TCG backend. And if the guest doesn't
behave correctly, it is hard to find the exact bug in backend.

Maybe I can run RISU on qemu-aarch64(x86) and qemu-aarch64(risc-v) to check the RISC-V backend.

  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.

We already have many ISAs as the front end of TCG. Will the virtual processor here be some
different?

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.
Sorry, I don't get it.
  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.

If I can find a  good way, I really like to do some further work.

Thanks,
Zhiwei





reply via email to

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