[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH V4 6/6] monitor: Add drift info to 'info jit
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [RFC PATCH V4 6/6] monitor: Add drift info to 'info jit' |
Date: |
Tue, 22 Jul 2014 12:19:42 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 |
Il 22/07/2014 11:58, Sebastian Tanase ha scritto:
>
> -timers_state.cpu_clock_offset contains the offset between the real and
> virtual clocks.
> However, when using the value of the virtual clock
> (qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL)),
> qemu_icount_bias already includes this offset because, on ARM,
> qemu_clock_warp (which
> then calls icount_warp_rt) is called for the first time in tcg_exec_all,
> making
> qemu_icount_bias take the value of qemu_clock_get_ns(QEMU_CLOCK_REALTIME)
Does this means that QEMU_CLOCK_VIRTUAL counts up from
qemu_clock_get_ns(QEMU_CLOCK_REALTIME) rather than 0? This would be a
bug, and it would be good to fix it (by initializing vm_clock_warp_start
to -1).
> A solution to not compute the initial offset in qemu_icount_bias would be to
> initialize
> vm_clock_warp_start to -1. The result will be that qemu_icount_bias will
> start counting when
> the vcpu goes from active to inactive. At that time, vm_clock_warp_start will
> already store the realtime clock
> value and a timer on the real clock will be set to expire at clock +
> deadline, making qemu_icount_bias increment
> by deadline.
That would be correct.
> A consequence of initializing vm_clock_warp_start to -1 is also
> the fact that we'll skip the first check for a virtual expired timer. As I
> mentioned above, in ARM case,
> it's not dangerous because there are no timers active the first time we
> perform this check. However, this
> is just a potential scenario and I cannot guarantee that on other target
> architectures there won't be
> an expired timer pending the first time we check.
Like a timer that expired in the past? That would be caught in
tcg_cpu_exec, when it initializes the decrementer to
qemu_clock_deadline_ns_all(QEMU_CLOCK_VIRTUAL).
> So, do you think it is worth taking this solution into account or it will
> cause more harm than good?
Yes, even more so. If we add workarounds to complicated code, it will
become even more complicated.
Paolo
[Qemu-devel] [RFC PATCH V4 5/6] cpu_exec: Print to console if the guest is late, Sebastian Tanase, 2014/07/16
[Qemu-devel] [RFC PATCH V4 2/6] icount: Add align option to icount, Sebastian Tanase, 2014/07/16
Re: [Qemu-devel] [RFC PATCH V4 0/6] icount: Implement delay algorithm between guest and host clocks, Paolo Bonzini, 2014/07/16
- Re: [Qemu-devel] [RFC PATCH V4 0/6] icount: Implement delay algorithm between guest and host clocks, Sebastian Tanase, 2014/07/22
- Re: [Qemu-devel] [RFC PATCH V4 0/6] icount: Implement delay algorithm between guest and host clocks, Paolo Bonzini, 2014/07/22
- Re: [Qemu-devel] [RFC PATCH V4 0/6] icount: Implement delay algorithm between guest and host clocks, Sebastian Tanase, 2014/07/22
- Re: [Qemu-devel] [RFC PATCH V4 0/6] icount: Implement delay algorithm between guest and host clocks, Paolo Bonzini, 2014/07/22
- Re: [Qemu-devel] [RFC PATCH V4 0/6] icount: Implement delay algorithm between guest and host clocks, Sebastian Tanase, 2014/07/22
- Re: [Qemu-devel] [RFC PATCH V4 0/6] icount: Implement delay algorithm between guest and host clocks, Paolo Bonzini, 2014/07/22