All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] Newcomer -- clock issue
@ 2015-05-17 20:23 françois Guerret
  2015-05-19  9:42 ` Victor Clement
  0 siblings, 1 reply; 2+ messages in thread
From: françois Guerret @ 2015-05-17 20:23 UTC (permalink / raw)
  To: qemu-devel

[-- Attachment #1: Type: text/plain, Size: 2086 bytes --]

Hello,

I am a newcomer on QEMU so I would like to ask a few questions about the way QEMU works before beginning to  develop.

After some experiments and after having read the source code I understood that the time (the clocks) on which the timers are based in QEMU depends:
on the host clock
on the scheduling policy of the host, since the timers seem to continue running even when qemu program execution is preempted by the host's OS. Actually, the timers seem to be based on "real time" (i mean watch clock) and not on a "machine time".on qemu execution time
What I would need is to base timers on a time which increase only when qemu is really running.
Actually, I want to control the execution time of some code thanks to timers and i need timers which "stop":
when qemu is preempted by the host OSwhen qemu is not running user code


Before going further, could you confirm me that there is no existing option which enables to do that ?

This may be (and may be not) how this problem could be solve  (just an ideas, not an implementation solution): to count the n instructions executed (at block level if it is too costly to do it at instruction level) on the target emulated since the last update and to increment timers with n*mean_execution_time_of_one instruction_on_target. This would not be very precise but better than nothing. It would be much less difficult than counting all instructions of each kind and multiply them by there proper mean execution time which would be a better solution (the very best solution should be to compute these times taking into account the access times to memory and caches which can change for every instruction ...).

Do you think it would be a good idea to specify and implement that solution to offer a supplementary option to the user ?
If yes, could you please explain me how I must proceed to offer a branch development to one of the current qemu version developped ?
If you have any idea about where to begin to deal with this issue, all suggestions are welcomed ...

Thanks in advance.

Francois 
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 2436 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [Qemu-devel] Newcomer -- clock issue
  2015-05-17 20:23 [Qemu-devel] Newcomer -- clock issue françois Guerret
@ 2015-05-19  9:42 ` Victor Clement
  0 siblings, 0 replies; 2+ messages in thread
From: Victor Clement @ 2015-05-19  9:42 UTC (permalink / raw)
  To: françois Guerret; +Cc: qemu-devel

Hello, 

Check the icount option, which uses the virtual cpu instrution counter
to calculate the value of QEMU_CLOCK_VIRTUAL. This is not exactly what
you want because the clock will still run when qemu is preempted by the
host but this is the closest thing you have.

I'm working on a patch that will enable using only the instruction
counter to get pure virtual time and will submit it next week.


Victor

----- Mail original -----
> De: "françois Guerret" <francois.guerret@hotmail.fr>
> À: qemu-devel@nongnu.org
> Envoyé: Dimanche 17 Mai 2015 22:23:43
> Objet: [Qemu-devel] Newcomer -- clock issue
> 
> 
> Hello,
> 
> I am a newcomer on QEMU so I would like to ask a few questions about
> the way QEMU works before beginning to develop.
> 
> After some experiments and after having read the source code I
> understood that the time (the clocks) on which the timers are based
> in QEMU depends:
> 
>     * on the host clock
>     * on the scheduling policy of the host, since the timers seem to
>     continue running even when qemu program execution is preempted
>     by the host's OS. Actually, the timers seem to be based on "real
>     time" (i mean watch clock) and not on a "machine time".
>     * on qemu execution time
> 
> What I would need is to base timers on a time which increase only
> when qemu is really running.
> Actually, I want to control the execution time of some code thanks to
> timers and i need timers which "stop":
> 
>     * when qemu is preempted by the host OS
>     * when qemu is not running user code
> 
> 
> Before going further, could you confirm me that there is no existing
> option which enables to do that ?
> 
> This may be (and may be not) how this problem could be solve (just an
> ideas, not an implementation solution): to count the n instructions
> executed (at block level if it is too costly to do it at instruction
> level) on the target emulated since the last update and to increment
> timers with n*mean_execution_time_of_one instruction_on_target. This
> would not be very precise but better than nothing. It would be much
> less difficult than counting all instructions of each kind and
> multiply them by there proper mean execution time which would be a
> better solution (the very best solution should be to compute these
> times taking into account the access times to memory and caches
> which can change for every instruction ...).
> 
> Do you think it would be a good idea to specify and implement that
> solution to offer a supplementary option to the user ?
> If yes, could you please explain me how I must proceed to offer a
> branch development to one of the current qemu version developped ?
> If you have any idea about where to begin to deal with this issue,
> all suggestions are welcomed ...
> 
> Thanks in advance.
> 
> Francois
> 

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-05-19  9:43 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-05-17 20:23 [Qemu-devel] Newcomer -- clock issue françois Guerret
2015-05-19  9:42 ` Victor Clement

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.