qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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));
> +

      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).