On Tue, Aug 06, 2013 at 03:18:13PM +0100, Alex Bligh wrote: > Stefan, > > --On 6 August 2013 15:59:11 +0200 Stefan Hajnoczi > <stefa...@gmail.com> wrote: > > >>--On 6 August 2013 14:02:18 +0200 Stefan Hajnoczi > >><stefa...@redhat.com> wrote: > >>My preference would be to move these to qemu_clock_deadline_ns (without > >>the INT32_MAX check) and delete the old qemu_clock_deadline routine > >>entirely, but I don't really understand the full set of circumstances > >>in which the qtest routines are meant to work. > > > >Okay, that's excellent. It would be great to move to a single function. > > > >The way qtest works is that it executes QEMU in a mode that does not run > >guest code. Instead of running guest code it listens for commands over > >a socket. The wire protocol can peek/poke memory, notify of interrupts, > >and warp the clock. > > > >There are test cases that use qtest to test emulated devices. > > > >When qtest either steps the clock or sets it to a completely new value > >using qtest_clock_warp() it runs all vm_clock timers that should expire > >before the new time. > > > >Does this help? > > Nearly :-) > > How do I actually run the code (i.e. how do I test whether I've broken > it)? I take it that's something different from just 'make check'?
make check includes qtest test cases like rtc-test, i440fx-test, fdc-test, and others. As long as they continue to pass all is good. Stefan
