From: Paolo Bonzini <pbonzini@redhat.com>
To: "James J. Nutaro" <nutarojj@ornl.gov>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v4] qqq: module for synchronizing with a simulation clock
Date: Mon, 2 Jan 2017 09:30:38 +0100 [thread overview]
Message-ID: <fe8b67b8-d430-a334-cd65-3528b6a9e74f@redhat.com> (raw)
In-Reply-To: <1482869621-24808-1-git-send-email-nutarojj@ornl.gov>
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));
> +
prev parent reply other threads:[~2017-01-02 8:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-27 20:13 [Qemu-devel] [PATCH v4] qqq: module for synchronizing with a simulation clock James J. Nutaro
2016-12-27 20:16 ` no-reply
2017-01-02 8:30 ` Paolo Bonzini [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fe8b67b8-d430-a334-cd65-3528b6a9e74f@redhat.com \
--to=pbonzini@redhat.com \
--cc=nutarojj@ornl.gov \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).