Re: [PATCH v4 3/3] tests/qtest: Introduce tests for AMD/Xilinx Versal TRNG device

[Peter Maydell]

On Mon, 30 Oct 2023 at 06:25, Ho, Tong <tong.ho@amd.com> wrote:
>
> Hi Peter,
>
> This is in regard to your comment on the use of g_usleep() in waiting for
> an event-bit update from the device under test.
>
> The TRNG device model presented in patch #1 does not have any asynchronous 
> behavior.
>
> So, do you mean that, although the qtest process and the qemu-system-* process
> are running as 2 separate processes, qtest infrastructure already has the 
> necessary
> mechanism to ensure that:
>
> 1. After qtest test sets a register that has the correct deterministic 
> behavior to update an event bit,
>
> 2. The same qtest test subsequently issuing a register read will be 
> guaranteed to observe the updated bit?

Yes. With a qtest test, there is no guest CPU inside QEMU. Instead
when the test says "write a register" there's a protocol between
the QEMU-under-test and the test process that says "write this
value to this address". Time within the simulation only advances
if the test specifically asks for it.

So if your device under test has the usual property of "we just
immediately update the state on register write" you're guarenteed
to see things on a subsequent read. If you are attempting a more
exact simulation and do things like "when this register is written
we set up a QEMU timer so that we only report the device ready
after a certain time" then your test needs to manually advance
the simulation clock with clock_step() to the point when the
device would report ready. (Usually we don't care about that
level of simulation accuracy, so clock_step() is used largely
in tests of timer devices.) Either way, this is unrelated to
wall-clock time.

thanks
-- PMM