[Qemu-devel] [PATCH] Timer/clock for Linux

[Qemu-devel] [PATCH] Timer/clock for Linux

[Kazu]

Hi,

I made a little patch of timer/clock for Linux host. It always trys to use
/dev/rtc.
getitimer doesn't report a correct interval value.

http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060407-linux-timer.patch

To get a precise timer/clock., do:
(1) Set max-user-freq 1024 as root.

[Linux host] # echo 1024 > /proc/sys/dev/rtc/max-user-freq

It is necessary to set it everytime you reboot the host OS. Write it to
/etc/rc.d/rc.local.

(2) Apply the patch and build a binary.

(1) is necessary and (2) is optional. I think latest kernel doesn't need the
patch. When I use 2.6.11-1.11369_FC4 host, it is necessary to apply (2). But
when 2.6.15-1.1831_FC4 host, it is not.

If you don't set max-user-freq, the clock in Windows 2000 guest is unstable
while IE is running.

Timer uses RTC(Real Time Clock). If it can not be used, setitimer/getitimer
are used.
If the timer's interval is set to 999 us, the interval becomes 2ms. It is
the
cause that a guest OS clock is 1/2 slow than the real time. Recent Linux
kernel is 4ms and clock is 1/4 slow.


Tested environments are:
Windows 2000 guest            /FC4 kernel-2.6.11-1.1831_FC4 host
FC4-i386-rescuecd.iso guest/FC4 kernel-2.6.11-1.1831_FC4 host

Windows 2000 guest            /FC4 kernel-2.6.15-1.1831_FC4 host
FC4-i386-rescuecd.iso guest/FC4 kernel-2.6.15-1.1831_FC4 host

I have not tested Linux 2.4 host.
The clock of guest OS on x86_64 host is unstable. 1ms interval interrupts
occure but the clock in Windows 2000 guest on x86_64 host doesn't work well.

Regards,
Kazu

[Qemu-devel] [PATCH] Fix message in configure

[Stefan Weil]

The help message for --disable-bfx-check should be fixed.

Regards

Stefan Weil



Index: configure
===================================================================
RCS file: /sources/qemu/qemu/configure,v
retrieving revision 1.87
diff -u -b -B -u -r1.87 configure
--- configure    8 Apr 2006 14:26:41 -0000    1.87
+++ configure    13 Apr 2006 18:02:29 -0000
@@ -649,7 +649,7 @@
if test "$target_user_only" = "no" -a "$check_gfx" = "yes" \
        -a "$sdl" = "no" -a "$cocoa" = "no" ; then
    echo "ERROR: QEMU requires SDL or Cocoa for graphical output"
-    echo "To build QEMU with graphical output configure with 
--disable-gfx-check"
+    echo "To build QEMU without graphical output configure with 
--disable-gfx-check"
    echo "Note that this will disable all output from the virtual 
graphics card."
    exit 1;
fi

Re: [Qemu-devel] [PATCH] Timer/clock for Linux

[Fabrice Bellard]

Hi,

Can other people confirm that it is better to always use /dev/rtc on 
Linux ? Is there a way to get the real resolution of the host timer ?

Fabrice.

Kazu wrote:
> Hi,
> 
> I made a little patch of timer/clock for Linux host. It always trys to use
> /dev/rtc.
> getitimer doesn't report a correct interval value.
> 
> http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060407-linux-timer.patch
> 
> To get a precise timer/clock., do:
> (1) Set max-user-freq 1024 as root.
> 
> [Linux host] # echo 1024 > /proc/sys/dev/rtc/max-user-freq
> 
> It is necessary to set it everytime you reboot the host OS. Write it to
> /etc/rc.d/rc.local.
> 
> (2) Apply the patch and build a binary.
> 
> (1) is necessary and (2) is optional. I think latest kernel doesn't need the
> patch. When I use 2.6.11-1.11369_FC4 host, it is necessary to apply (2). But
> when 2.6.15-1.1831_FC4 host, it is not.
> 
> If you don't set max-user-freq, the clock in Windows 2000 guest is unstable
> while IE is running.
> 
> Timer uses RTC(Real Time Clock). If it can not be used, setitimer/getitimer
> are used.
> If the timer's interval is set to 999 us, the interval becomes 2ms. It is
> the
> cause that a guest OS clock is 1/2 slow than the real time. Recent Linux
> kernel is 4ms and clock is 1/4 slow.
> 
> 
> Tested environments are:
> Windows 2000 guest            /FC4 kernel-2.6.11-1.1831_FC4 host
> FC4-i386-rescuecd.iso guest/FC4 kernel-2.6.11-1.1831_FC4 host
> 
> Windows 2000 guest            /FC4 kernel-2.6.15-1.1831_FC4 host
> FC4-i386-rescuecd.iso guest/FC4 kernel-2.6.15-1.1831_FC4 host
> 
> I have not tested Linux 2.4 host.
> The clock of guest OS on x86_64 host is unstable. 1ms interval interrupts
> occure but the clock in Windows 2000 guest on x86_64 host doesn't work well.
> 
> Regards,
> Kazu
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 
> 

Re: [Qemu-devel] [PATCH] Timer/clock for Linux

[Jamie Lokier]

Fabrice Bellard wrote:
> Can other people confirm that it is better to always use /dev/rtc on 
> Linux ? Is there a way to get the real resolution of the host timer ?

Yes, on recent Linux kernels you can do
clock_getres(CLOCK_MONOTONIC,&ts) [or CLOCK_REALTIME], and it will
return the length of a timer tick.  On my kernel it's 4.00025 ms.  On
other x86 kernels it can be ~10ms or ~1ms.

Also the recent Linux kernels (more recent) offer "high-resolution
timers"; you can guess what that means.  They should be more accurate
than /dev/rtc when they're available, because they reprogram the timer
chip, though I have never tried them.  I'd guess that kernels
featuring them would return a small value from clock_getres().

It's unfortunate that even on kernels where the kernel tick time is
1ms, setitimer() will cost you a 2ms delay.  But: why should that make
Windows run slower?  Doesn't qemu read the kernel clock to determine
that the guest is due approx. 2 timer interrupts for each host wakeup?
Naturally you can't let that count increase indefinitely, if the
emulator is too slow to run the guest at full speed, but it might be
an idea to count up to a small number, so that short pauses in host
kernel scheduling won't cause a guest to lose time.

-- Jamie

Re: [Qemu-devel] [PATCH] Timer/clock for Linux

[NyOS]

On Mon, 24 Apr 2006 23:41:23 +0200, Fabrice Bellard <fabrice@bellard.org>  
wrote:

> Hi,
>
> Can other people confirm that it is better to always use /dev/rtc on  
> Linux ? Is there a way to get the real resolution of the host timer ?
>
> Fabrice.

Hi!

There must be one.
Mplayer says this after setting /proc/sys/dev/rtc/max-user-freq below 1024:

Linux RTC init error in ioctl (rtc_irqp_set 1024): Permission denied
Try adding "echo 1024 > /proc/sys/dev/rtc/max-user-freq" to your system  
startup scripts.
Using nanosleep() timing

URL=http://mplayerhq.hu/homepage/design7/dload.html

this code can be found in mplayer.c file aprox. 1100th line:

#ifdef HAVE_RTC
   if(!nortc)
   {
     // seteuid(0); /* Can't hurt to try to get root here */
     if ((rtc_fd = open(rtc_device ? rtc_device : "/dev/rtc", O_RDONLY)) <  
0)
	mp_msg(MSGT_CPLAYER, MSGL_WARN, "Failed to open %s: %s (it should be  
readable by the user.)\n",
	    rtc_device ? rtc_device : "/dev/rtc", strerror(errno));
      else {
	unsigned long irqp = 1024; /* 512 seemed OK. 128 is jerky. */

	if (ioctl(rtc_fd, RTC_IRQP_SET, irqp) < 0) {
     	    mp_msg(MSGT_CPLAYER, MSGL_WARN, "Linux RTC init error in ioctl  
(rtc_irqp_set %lu): %s\n", irqp, strerror(errno));
	    mp_msg(MSGT_CPLAYER, MSGL_HINT, "Try adding \"echo %lu >  
/proc/sys/dev/rtc/max-user-freq\" to your system startup scripts.\n",  
irqp);
    	    close (rtc_fd);
     	    rtc_fd = -1;
	} else if (ioctl(rtc_fd, RTC_PIE_ON, 0) < 0) {
	    /* variable only by the root */
     	    mp_msg(MSGT_CPLAYER, MSGL_ERR, "Linux RTC init error in ioctl  
(rtc_pie_on): %s\n", strerror(errno));
     	    close (rtc_fd);
	    rtc_fd = -1;
	} else
	    mp_msg(MSGT_CPLAYER, MSGL_INFO, MSGTR_UsingRTCTiming, irqp);
     }
   }

I've never used RTC in my programs, but ioctl seems to return negative  
value on such an error. A hint like that can also be good on startup.

Miklos Gyozo (Nyos)

Re: [Qemu-devel] [PATCH] Timer/clock for Linux

[Fabrice Bellard]

Jamie Lokier wrote:
> Fabrice Bellard wrote:
> 
>>Can other people confirm that it is better to always use /dev/rtc on 
>>Linux ? Is there a way to get the real resolution of the host timer ?
> 
> 
> Yes, on recent Linux kernels you can do
> clock_getres(CLOCK_MONOTONIC,&ts) [or CLOCK_REALTIME], and it will
> return the length of a timer tick.  On my kernel it's 4.00025 ms.  On
> other x86 kernels it can be ~10ms or ~1ms.
> 
> Also the recent Linux kernels (more recent) offer "high-resolution
> timers"; you can guess what that means.  They should be more accurate
> than /dev/rtc when they're available, because they reprogram the timer
> chip, though I have never tried them.  I'd guess that kernels
> featuring them would return a small value from clock_getres().

Using clock_getres() seems a good idea if I can test that it is 
supported. If it is not supported then /dev/rtc will be used in any case.

> It's unfortunate that even on kernels where the kernel tick time is
> 1ms, setitimer() will cost you a 2ms delay.  But: why should that make
> Windows run slower?  Doesn't qemu read the kernel clock to determine
> that the guest is due approx. 2 timer interrupts for each host wakeup?
> Naturally you can't let that count increase indefinitely, if the
> emulator is too slow to run the guest at full speed, but it might be
> an idea to count up to a small number, so that short pauses in host
> kernel scheduling won't cause a guest to lose time.

QEMU reads the clock at each host wakeup, but it cannot compensate if 
the guest OS requires a higher frequency than the host timer frequency. 
Having a 1 ms period is definitively better to be able to run a wide 
range of guest OSes.

Fabrice.

Re: [Qemu-devel] [PATCH] Timer/clock for Linux

[Jamie Lokier]

Fabrice Bellard wrote:
> Jamie Lokier wrote:
> >Fabrice Bellard wrote:
> >
> >>Can other people confirm that it is better to always use /dev/rtc on 
> >>Linux ? Is there a way to get the real resolution of the host timer ?
> >
> >
> >Yes, on recent Linux kernels you can do
> >clock_getres(CLOCK_MONOTONIC,&ts) [or CLOCK_REALTIME], and it will
> >return the length of a timer tick.  On my kernel it's 4.00025 ms.  On
> >other x86 kernels it can be ~10ms or ~1ms.
> >
> >Also the recent Linux kernels (more recent) offer "high-resolution
> >timers"; you can guess what that means.  They should be more accurate
> >than /dev/rtc when they're available, because they reprogram the timer
> >chip, though I have never tried them.  I'd guess that kernels
> >featuring them would return a small value from clock_getres().
> 
> Using clock_getres() seems a good idea if I can test that it is 
> supported. If it is not supported then /dev/rtc will be used in any case.

You'll need to check for -lrt, something like this:

    AC_SEARCH_LIBS([clock_getres], [rt posix4])

> >It's unfortunate that even on kernels where the kernel tick time is
> >1ms, setitimer() will cost you a 2ms delay.  But: why should that make
> >Windows run slower?  Doesn't qemu read the kernel clock to determine
> >that the guest is due approx. 2 timer interrupts for each host wakeup?
> >Naturally you can't let that count increase indefinitely, if the
> >emulator is too slow to run the guest at full speed, but it might be
> >an idea to count up to a small number, so that short pauses in host
> >kernel scheduling won't cause a guest to lose time.
> 
> QEMU reads the clock at each host wakeup, but it cannot compensate if 
> the guest OS requires a higher frequency than the host timer frequency. 
> Having a 1 ms period is definitively better to be able to run a wide 
> range of guest OSes.

I was thinking that if the host is woken later than it intended
(e.g. after 2ms with setitimer; could be any amount with any syscall
due to other scheduling delays), then it could fake the timer chip
time it presents to the guest for a short while as if there wasn't
really a timing gap, effectively delaying the faked clock for that
gap, and then running the faked clock faster than normal to catch up
with real time.  A control loop would ensure the amount of adjustment
stays small, converting to slippage if that's not possible.  In this
way a guest would get 1000Hz interrupts (if that's what it wants), or
any other frequency.  It would also read the values it's expecting
from the emulated timer chip as if there was no host scheduling gap,
so the guest's timing logic would function properly, counting ticks,
timing times, and still tracking real clock time.

-- Jamie

Re: [Qemu-devel] [PATCH] Timer/clock for Linux

[Paul Brook]

> > QEMU reads the clock at each host wakeup, but it cannot compensate if
> > the guest OS requires a higher frequency than the host timer frequency.
> > Having a 1 ms period is definitively better to be able to run a wide
> > range of guest OSes.
>
> I was thinking that if the host is woken later than it intended
> (e.g. after 2ms with setitimer; could be any amount with any syscall
> due to other scheduling delays), then it could fake the timer chip
> time it presents to the guest for a short while as if there wasn't
> really a timing gap, 

This isn't possible with the current system. Qemu uses host signals to 
interrupt itself, ie. to stop executing guest code and process pending 
interrupts. Thus the minimum available length of a "short delay" is bounded 
buy the signal latency that you're trying to compensate for.

One solution (which is also desirable for other reasons) is to implement some 
form of guest cycle counting based on the instructions actually executed. 
Then use that as the high-precision timesource, and use some for of adaptive 
method to keep host and guest clocks in sync.

Paul

Re: [Qemu-devel] [PATCH] Timer/clock for Linux

[Jamie Lokier]

Paul Brook wrote:
> One solution (which is also desirable for other reasons) is to
> implement some form of guest cycle counting based on the
> instructions actually executed.  Then use that as the high-precision
> timesource, and use some for of adaptive method to keep host and
> guest clocks in sync.

That's what I meant, expressed more clearly, except that I meant to
count guest time based on the real time spent executing guest code,
rather than counting individual instructions.  Thanks!

-- Jamie

Re: [Qemu-devel] [PATCH] Timer/clock for Linux

[Paul Brook]

On Wednesday 26 April 2006 14:01, Jamie Lokier wrote:
> Paul Brook wrote:
> > One solution (which is also desirable for other reasons) is to
> > implement some form of guest cycle counting based on the
> > instructions actually executed.  Then use that as the high-precision
> > timesource, and use some for of adaptive method to keep host and
> > guest clocks in sync.
>
> That's what I meant, expressed more clearly, except that I meant to
> count guest time based on the real time spent executing guest code,
> rather than counting individual instructions.  Thanks!

How do you propose doing that? It implies you have some way of interrupting 
the guest after it has executed a small amount of guest code, where "small" 
is less than the resolution+latency of host timer interrupts.

Paul

Re: [Qemu-devel] [PATCH] Timer/clock for Linux

[Jamie Lokier]

Paul Brook wrote:
> On Wednesday 26 April 2006 14:01, Jamie Lokier wrote:
> > Paul Brook wrote:
> > > One solution (which is also desirable for other reasons) is to
> > > implement some form of guest cycle counting based on the
> > > instructions actually executed.  Then use that as the high-precision
> > > timesource, and use some for of adaptive method to keep host and
> > > guest clocks in sync.
> >
> > That's what I meant, expressed more clearly, except that I meant to
> > count guest time based on the real time spent executing guest code,
> > rather than counting individual instructions.  Thanks!
> 
> How do you propose doing that? It implies you have some way of interrupting 
> the guest after it has executed a small amount of guest code, where "small" 
> is less than the resolution+latency of host timer interrupts.

Hmm.  I hadn't thought that through, but it still works.

It doesn't matter if the guest runs, say, for 20ms before its next
emulated 1kHz interrupt - so long as it's not dependent on values from
the emulated timer chip after 1ms (or any other emulated device which
reveals the time).

If the guest does read a device which depends on the time, that's an
opportunity to interrupt it.  Otherwise, from the guest's view, it's
just as if the emulated CPU got faster for a while with the interrupts
perfectly timed.

-- Jamie