On 25 apr 2005, at 23:46, Massimo Dal Zotto wrote:
No, it has nothing to do with the speed of gettimeofday, which on my pc
takes only a few microsecons to execute.
Sorry, I had misread the original remark: I thought it was asking why
qemu suddenly ran (supposedly) 20% slower when calling gettimeof
On Monday 25 April 2005 04:15, Massimo Dal Zotto wrote:
> When qemu runs on an i386 cpu with speedstep enabled the clock of the
> guest os is not in sync with the clock on the host os because the
> vm_timer used for irq 0 generates interrupts at wrong rate when
> the host cpu frequency changes.
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Filip Navara wrote:
> Jonas Maebe wrote:
>
>> On 25 Apr 2005, at 22:17, Massimo Dal Zotto wrote:
>>
>>> In the meantime until we find a better solution could you give
>>> us some explanation on why using a microseconds clock from
>>> gettimeofday inst
On Mon, Apr 25, 2005 at 10:24:45PM +0200, Jonas Maebe wrote:
>
> On 25 Apr 2005, at 22:17, Massimo Dal Zotto wrote:
>
> >In the meantime until we find a better solution could you give us some
> >explanation on why using a microseconds clock from gettimeofday instead
> >of rdtsc the guest os clock
On Mon, Apr 25, 2005 at 10:38:42PM +0200, Filip Navara wrote:
> (Once again Windows NT were ahead of time with this idea implemented way
> earlier ;-)
Strange, I got report from people testing stuff in Wine (about the same
RTDSC problem with laptops) finding out that 'gettimeofday' was taking les
Jonas Maebe wrote:
On 25 Apr 2005, at 22:17, Massimo Dal Zotto wrote:
In the meantime until we find a better solution could you give us some
explanation on why using a microseconds clock from gettimeofday instead
of rdtsc the guest os clock runs always 20% slower?
Because a system call (which getti
On 25 Apr 2005, at 22:17, Massimo Dal Zotto wrote:
In the meantime until we find a better solution could you give us some
explanation on why using a microseconds clock from gettimeofday instead
of rdtsc the guest os clock runs always 20% slower?
Because a system call (which gettimeofday is) is very
On Mon, Apr 25, 2005 at 08:58:06PM +0200, Fabrice Bellard wrote:
>
> This is not the best way to fix the bug. I see 4 solutions:
>
> - Compute ticks_per_sec every n seconds and update the timers accordingly.
This won't work well if an userpace scaling governor is continuously
changing the cpu fr
Massimo Dal Zotto wrote:
When qemu runs on an i386 cpu with speedstep enabled the clock of the
guest os is not in sync with the clock on the host os because the
vm_timer used for irq 0 generates interrupts at wrong rate when
the host cpu frequency changes.
The problem is that the vm_timer uses the
On Mon, Apr 25, 2005 at 01:07:52PM -0400, Jim C. Brown wrote:
>
> I just want to point out that your patches break qemu for almost every
> platform other than i386.
>
> You probably want to do this, because notsc is only declared for the i386
> platform.
>
> int64_t cpu_get_real_ticks(void)
>
On Monday 25 April 2005 18:07, Jim C. Brown wrote:
> On Mon, Apr 25, 2005 at 01:15:32PM +0200, Massimo Dal Zotto wrote:
> > The patch works for me but I don't know if this is the best way of fixing
> > this bug. If anyone has a better suggestion it is welcome.
> >
> > --
> > Massimo Dal Zotto <[EMA
On Mon, Apr 25, 2005 at 01:15:32PM +0200, Massimo Dal Zotto wrote:
> The patch works for me but I don't know if this is the best way of fixing
> this bug. If anyone has a better suggestion it is welcome.
>
> --
> Massimo Dal Zotto <[EMAIL PROTECTED]>
I just want to point out that your patches br
When qemu runs on an i386 cpu with speedstep enabled the clock of the
guest os is not in sync with the clock on the host os because the
vm_timer used for irq 0 generates interrupts at wrong rate when
the host cpu frequency changes.
The problem is that the vm_timer uses the rdtsc instruction and th
13 matches
Mail list logo
