Thanks for the review Emilio.
>> Isn't this a KVM-only feature though? I don't see calls to qqq_sync()
>> anywhere but from kvm-all.c, but maybe I'm missing something.
There is another call in the timer callback in qqq.c that gets invoked when
using
the -icount mode.
>> Also, a few more comments:
>> - Why "qqq" as the name for this feature? I fail to see any
>> connection between the name and the feature.
There was a similar package called qbox, and I got stuck thinking of a name.
So I somewhat unimaginatively just stuttered on the q. I'm open to a better
name.
>> If Windows users ever wanted this feature, would we have to
>> change the user-facing API (i.e. the -qqq parameter)?
It will (or should) ignore the -qqq option on Windows. But I'll double check
that.
>> As is, isn't the code Unix-only rather than Linux-only?
Yes, Unix-only. You are correct.
Jim
________________________________________
From: Emilio G. Cota <c...@braap.org>
Sent: Friday, June 02, 2017 10:42 AM
To: Nutaro, James J.
Cc: qemu-devel@nongnu.org; pbonz...@redhat.com
Subject: Re: [Qemu-devel] [PATCH V8] qqq: module for synchronizing with a
simulation
On Tue, Feb 14, 2017 at 13:37:56 -0500, James J. Nutaro wrote:
> This patch adds an interface for pacing the execution of QEMU to match an
> external
> simulation clock. Its aim is to permit QEMU to be used as a module within a
> larger simulation system.
(snip)
> +++ b/docs/simulation-sync.txt
> @@ -0,0 +1,59 @@
> += Synchronizing the virtual clock with an external source =
> +
> +QEMU has a protocol for synchronizing its virtual clock
> +with the clock of a simulator in which QEMU is embedded
> +as a component. This options is enabled with the -qqq
> +argument, and it should generally be accompanied by the
> +following additional command line arguments:
> +
> +-icount 1,sleep=off -rtc clock=vm
> + or
> +-enable-kvm -rtc clock=vm
Isn't this a KVM-only feature though? I don't see calls to qqq_sync()
anywhere but from kvm-all.c, but maybe I'm missing something.
Also, a few more comments:
- Why "qqq" as the name for this feature? I fail to see any
connection between the name and the feature.
- If Windows users ever wanted this feature, would we have to
change the user-facing API (i.e. the -qqq parameter)?
- As is, isn't the code Unix-only rather than Linux-only?
Thanks,
Emilio
