On Mon, 30 Oct 2023 at 06:25, Ho, Tong <tong...@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
