On 27/12/2016 21:13, James J. Nutaro wrote:
> +(1) Create two pairs of pipes with the Linux pipe function.
> + The code segment that does this might look like
> +
> + int pipefd1[2];
> + int pipefd2[2];
> + pipe(pipefd1);
> + pipe(pipefd2);
> +
> +(2) Fork QEMU with the appropriate command line arguments.
> + The -qqq part of the argument will look something like
> +
> + -qqq write=pipefd1[1],read=pipefd2[0]
If you need a pair of pipes, you might as well use a Unix socket or even
a generic chardev. This would give something like
-chardev socket,path=extclock.socket \
-icount 1,extclock=chardev
> +The synchronization protocol is very simple. To start, the
> +external simulator writes an integer to its write pipe with
> +the amount of time in microseconds that QEMU is allowed to
> +advance. The code segment that does this might look like:
> +
> + int ta = 1000; // Advance by 1 millisecond
> + write(pipefd2[1],&ta,sizeof(int));
This makes the protocol depend on system endianness. Please make it
endian independent.
Regarding the implementation, note that the "frozen clock" is already
implemented by cpu_disable_ticks() and cpu_enable_ticks(), so it would
be (much) better if you can reuse that.
These are not small details, granted, but the concept looks interesting.
I'm sorry I didn't notice the first 3 versions. I look forward to
review the next iteration of the patch!
Paolo
> +The external simulator can then advance its clock by this
> +same amount. During this time, QEMU and the external simulator
> +will be executing in parallel. When the external simulator
> +completes its time advance, it waits for QEMU by reading from
> +its read pipe. The value read will be the actual number of
> +virtual microseconds by which QEMU has advanced its virtual clock.
> +This will be greater than or equal to the requested advance.
> +The code that does this might look like:
> +
> + read(pipefd1[0],&ta,sizeof(int));
> +
