[Qemu-devel] testing qemu svn r5890 on FreeBSD - virtio, and a patch enabling -clock dynticks

[Qemu-devel] testing qemu svn r5890 on FreeBSD - virtio, and a patch enabling -clock dynticks

[Juergen Lock]

Hi!

 Jung-uk Kim sent me a patch to enable -clock dynticks on FreeBSD hosts
(the configure check is mine, only FreeBSD >= 7.x has posix timers that
this uses), I'll append it below.

 This is the experimental qemu-devel port update I used:
	http://people.freebsd.org/~nox/qemu/qemu-devel-20081206.patch
As already mentioned I had to add a missing `#include <sys/uio.h>'
(files/patch-qemu-common.h), as also posted here:
	http://lists.gnu.org/archive/html/qemu-devel/2008-12/msg00216.html

 I only had one (type of) guest that actually had virtio drivers (three
versions of sidux isos), and the speed difference between virtio-blk and
scsi was small.  (I tested dd bs=64k count=500 </dev/vda >/dev/null and
similar with a raw image, both scsi and virtio were always faster than ide.)
I noted tho that even virtio there was not half as fast as ide (and scsi)
on KNOPPIX_V5.3.1DVD-2008-03-26-EN.iso, so either overhead has increased
greatly from 2.6.24.4 to 2.6.26, or this has something to do with
the sidux kernel using CONFIG_NO_HZ and the Knoppix one (apparently) not
and qemu (possibly, I also suspected that with the usb slowness) not
handling CONFIG_NO_HZ guests too well.  scsi on a FreeBSD
7.1-BETA-i386-livefs.iso guest btw was even yet (noticeably) faster than
on the Knoppix iso.  It will be interesting how virtio-net will fare once
that gets committed...

 Here comes the dynticks patch (files/patch-dynticks), it assumes that
NetBSD either always has posix timers, or -lrt is not needed otherwise
there.  (FreeBSD before 7.x doesn't have -lrt.)

--- qemu/Makefile.target.orig	2008-11-21 11:49:37.000000000 -0500
+++ qemu/Makefile.target	2008-12-03 15:46:24.000000000 -0500
@@ -598,7 +598,7 @@
 OBJS+=block-raw-posix.o
 endif
 
-LIBS+=-lz
+LIBS += $(RTLIBS) -lz
 ifdef CONFIG_ALSA
 LIBS += -lasound
 endif
Index: qemu/configure
@@ -99,6 +99,7 @@
 fmod_lib=""
 fmod_inc=""
 oss_lib=""
+rt_lib=""
 vnc_tls="yes"
 bsd="no"
 linux="no"
@@ -157,13 +158,15 @@
 if [ "$cpu" = "i386" -o "$cpu" = "x86_64" ] ; then
     kqemu="yes"
 fi
+rt_lib="-lrt"
 ;;
 NetBSD)
 bsd="yes"
 audio_drv_list="oss"
 audio_possible_drivers="oss sdl esd"
 oss_lib="-lossaudio"
-aio_lib="-lrt -lpthread"
+aio_lib="-lpthread"
+rt_lib="-lrt"
 ;;
 OpenBSD)
 bsd="yes"
@@ -231,6 +234,7 @@
     kqemu="yes"
     audio_possible_drivers="$audio_possible_drivers fmod"
 fi
+rt_lib="-lrt"
 ;;
 esac
 
@@ -1053,6 +1057,20 @@
   iovec=yes
 fi
 
+##########################################
+# posix timer probe
+cat > $TMPC <<EOF
+#include <time.h>
+int main(void) { timer_create(CLOCK_REALTIME, (struct sigevent *)NULL, (timer_t *)NULL); return 0; }
+EOF
+posixtimer=no
+if $cc $ARCH_CFLAGS -o $TMPE $TMPC $rt_lib 2> /dev/null ; then
+  posixtimer=yes
+else
+  rt_lib=""
+fi
+RTLIBS="$rt_lib"
+
 # Check if tools are available to build documentation.
 if [ "x$NOPORTDOCS" != "x" -o -x "`which texi2html 2>/dev/null`" ] && \
    [ -x "`which pod2man 2>/dev/null`" ]; then
@@ -1174,6 +1192,7 @@
 echo "LDFLAGS=$LDFLAGS" >> $config_mak
 echo "EXESUF=$EXESUF" >> $config_mak
 echo "AIOLIBS=$AIOLIBS" >> $config_mak
+echo "RTLIBS=$RTLIBS" >> $config_mak
 case "$cpu" in
   i386)
     echo "ARCH=i386" >> $config_mak
@@ -1425,6 +1444,9 @@
 if test "$iovec" = "yes" ; then
   echo "#define HAVE_IOVEC 1" >> $config_h
 fi
+if test "$posixtimer" = "yes" ; then
+  echo "#define HAVE_POSIX_TIMER 1" >> $config_h
+fi
 
 # XXX: suppress that
 if [ "$bsd" = "yes" ] ; then
Index: qemu/vl.c
@@ -918,12 +918,16 @@
 static int unix_start_timer(struct qemu_alarm_timer *t);
 static void unix_stop_timer(struct qemu_alarm_timer *t);
 
-#ifdef __linux__
+#ifdef HAVE_POSIX_TIMER
 
 static int dynticks_start_timer(struct qemu_alarm_timer *t);
 static void dynticks_stop_timer(struct qemu_alarm_timer *t);
 static void dynticks_rearm_timer(struct qemu_alarm_timer *t);
 
+#endif
+
+#ifdef __linux__
+
 static int hpet_start_timer(struct qemu_alarm_timer *t);
 static void hpet_stop_timer(struct qemu_alarm_timer *t);
 
@@ -1001,9 +1005,11 @@
 
 static struct qemu_alarm_timer alarm_timers[] = {
 #ifndef _WIN32
-#ifdef __linux__
+#ifdef HAVE_POSIX_TIMER
     {"dynticks", ALARM_FLAG_DYNTICKS, dynticks_start_timer,
      dynticks_stop_timer, dynticks_rearm_timer, NULL},
+#endif
+#ifdef __linux__
     /* HPET - if available - is preferred */
     {"hpet", 0, hpet_start_timer, hpet_stop_timer, NULL, NULL},
     /* ...otherwise try RTC */
@@ -1361,7 +1367,7 @@
     return delta;
 }
 
-#if defined(__linux__) || defined(_WIN32)
+#if defined(HAVE_POSIX_TIMER) || defined(_WIN32)
 static uint64_t qemu_next_deadline_dyntick(void)
 {
     int64_t delta;
@@ -1506,6 +1512,10 @@
     close(rtc_fd);
 }
 
+#endif /* defined(__linux__) */
+
+#ifdef HAVE_POSIX_TIMER
+
 static int dynticks_start_timer(struct qemu_alarm_timer *t)
 {
     struct sigevent ev;
@@ -1577,7 +1587,7 @@
     }
 }
 
-#endif /* defined(__linux__) */
+#endif /* defined(HAVE_POSIX_TIMER) */
 
 static int unix_start_timer(struct qemu_alarm_timer *t)
 {

[Qemu-devel] usb slowness again (was: testing qemu svn r5890 on FreeBSD - virtio, and a patch enabling -clock dynticks)

[Juergen Lock]

On Sat, Dec 06, 2008 at 11:09:06PM +0100, Juergen Lock wrote:
> Hi!
> 
>  Jung-uk Kim sent me a patch to enable -clock dynticks on FreeBSD hosts
> (the configure check is mine, only FreeBSD >= 7.x has posix timers that
> this uses), I'll append it below.
> 
>  This is the experimental qemu-devel port update I used:
> 	http://people.freebsd.org/~nox/qemu/qemu-devel-20081206.patch
> As already mentioned I had to add a missing `#include <sys/uio.h>'
> (files/patch-qemu-common.h), as also posted here:
> 	http://lists.gnu.org/archive/html/qemu-devel/2008-12/msg00216.html
> 
>  I only had one (type of) guest that actually had virtio drivers (three
> versions of sidux isos), and the speed difference between virtio-blk and
> scsi was small.  (I tested dd bs=64k count=500 </dev/vda >/dev/null and
> similar with a raw image, both scsi and virtio were always faster than ide.)
> I noted tho that even virtio there was not half as fast as ide (and scsi)
> on KNOPPIX_V5.3.1DVD-2008-03-26-EN.iso, so either overhead has increased
> greatly from 2.6.24.4 to 2.6.26, or this has something to do with
> the sidux kernel using CONFIG_NO_HZ and the Knoppix one (apparently) not
> and qemu (possibly, I also suspected that with the usb slowness) not
> handling CONFIG_NO_HZ guests too well.  [...]

Well I just tried -usb -usbdevice net:vlan=1 -net user,vlan=1 with the
Knoppix iso and got the same thruput (< 40 K/s) for wget on a local
file than I got with sidux.  So its probably not CONFIG_NO_HZ, at least
not the usb slowness.

 Just thought I'd mention...
	Juergen

Re: [Qemu-devel] testing qemu svn r5890 on FreeBSD - virtio, and a patch enabling -clock dynticks

[Anthony Liguori]

Juergen Lock wrote:
> Hi!
>
>  Jung-uk Kim sent me a patch to enable -clock dynticks on FreeBSD hosts
> (the configure check is mine, only FreeBSD >= 7.x has posix timers that
> this uses), I'll append it below.
>
>  This is the experimental qemu-devel port update I used:
> 	http://people.freebsd.org/~nox/qemu/qemu-devel-20081206.patch
> As already mentioned I had to add a missing `#include <sys/uio.h>'
> (files/patch-qemu-common.h), as also posted here:
> 	http://lists.gnu.org/archive/html/qemu-devel/2008-12/msg00216.html
>
>  I only had one (type of) guest that actually had virtio drivers (three
> versions of sidux isos), and the speed difference between virtio-blk and
> scsi was small.  (I tested dd bs=64k count=500 </dev/vda >/dev/null and
> similar with a raw image, both scsi and virtio were always faster than ide.)
> I noted tho that even virtio there was not half as fast as ide (and scsi)
> on KNOPPIX_V5.3.1DVD-2008-03-26-EN.iso, so either overhead has increased
> greatly from 2.6.24.4 to 2.6.26, or this has something to do with
> the sidux kernel using CONFIG_NO_HZ and the Knoppix one (apparently) not
> and qemu (possibly, I also suspected that with the usb slowness) not
> handling CONFIG_NO_HZ guests too well.  scsi on a FreeBSD
> 7.1-BETA-i386-livefs.iso guest btw was even yet (noticeably) faster than
> on the Knoppix iso.  It will be interesting how virtio-net will fare once
> that gets committed...
>   

I don't have much experience with perf benchmarking and TCG.  TCG may 
has interesting side effects.  For instance, it's more expensive to do 
things in the guest instead of the host so the emulation overhead of 
IDE/SCSI shouldn't matter much.

A straight dd test is not the best test BTW.  If you want to measure 
performance, you should use O_DIRECT in the guest (iflag=direct) and 
probably O_DIRECT in the host (cache=none).

Regards,

Anthony Liguori

>  Here comes the dynticks patch (files/patch-dynticks), it assumes that
> NetBSD either always has posix timers, or -lrt is not needed otherwise
> there.  (FreeBSD before 7.x doesn't have -lrt.)
>
> --- qemu/Makefile.target.orig	2008-11-21 11:49:37.000000000 -0500
> +++ qemu/Makefile.target	2008-12-03 15:46:24.000000000 -0500
> @@ -598,7 +598,7 @@
>  OBJS+=block-raw-posix.o
>  endif
>  
> -LIBS+=-lz
> +LIBS += $(RTLIBS) -lz
>  ifdef CONFIG_ALSA
>  LIBS += -lasound
>  endif
> Index: qemu/configure
> @@ -99,6 +99,7 @@
>  fmod_lib=""
>  fmod_inc=""
>  oss_lib=""
> +rt_lib=""
>  vnc_tls="yes"
>  bsd="no"
>  linux="no"
> @@ -157,13 +158,15 @@
>  if [ "$cpu" = "i386" -o "$cpu" = "x86_64" ] ; then
>      kqemu="yes"
>  fi
> +rt_lib="-lrt"
>  ;;
>  NetBSD)
>  bsd="yes"
>  audio_drv_list="oss"
>  audio_possible_drivers="oss sdl esd"
>  oss_lib="-lossaudio"
> -aio_lib="-lrt -lpthread"
> +aio_lib="-lpthread"
> +rt_lib="-lrt"
>  ;;
>  OpenBSD)
>  bsd="yes"
> @@ -231,6 +234,7 @@
>      kqemu="yes"
>      audio_possible_drivers="$audio_possible_drivers fmod"
>  fi
> +rt_lib="-lrt"
>  ;;
>  esac
>  
> @@ -1053,6 +1057,20 @@
>    iovec=yes
>  fi
>  
> +##########################################
> +# posix timer probe
> +cat > $TMPC <<EOF
> +#include <time.h>
> +int main(void) { timer_create(CLOCK_REALTIME, (struct sigevent *)NULL, (timer_t *)NULL); return 0; }
> +EOF
> +posixtimer=no
> +if $cc $ARCH_CFLAGS -o $TMPE $TMPC $rt_lib 2> /dev/null ; then
> +  posixtimer=yes
> +else
> +  rt_lib=""
> +fi
> +RTLIBS="$rt_lib"
> +
>  # Check if tools are available to build documentation.
>  if [ "x$NOPORTDOCS" != "x" -o -x "`which texi2html 2>/dev/null`" ] && \
>     [ -x "`which pod2man 2>/dev/null`" ]; then
> @@ -1174,6 +1192,7 @@
>  echo "LDFLAGS=$LDFLAGS" >> $config_mak
>  echo "EXESUF=$EXESUF" >> $config_mak
>  echo "AIOLIBS=$AIOLIBS" >> $config_mak
> +echo "RTLIBS=$RTLIBS" >> $config_mak
>  case "$cpu" in
>    i386)
>      echo "ARCH=i386" >> $config_mak
> @@ -1425,6 +1444,9 @@
>  if test "$iovec" = "yes" ; then
>    echo "#define HAVE_IOVEC 1" >> $config_h
>  fi
> +if test "$posixtimer" = "yes" ; then
> +  echo "#define HAVE_POSIX_TIMER 1" >> $config_h
> +fi
>  
>  # XXX: suppress that
>  if [ "$bsd" = "yes" ] ; then
> Index: qemu/vl.c
> @@ -918,12 +918,16 @@
>  static int unix_start_timer(struct qemu_alarm_timer *t);
>  static void unix_stop_timer(struct qemu_alarm_timer *t);
>  
> -#ifdef __linux__
> +#ifdef HAVE_POSIX_TIMER
>  
>  static int dynticks_start_timer(struct qemu_alarm_timer *t);
>  static void dynticks_stop_timer(struct qemu_alarm_timer *t);
>  static void dynticks_rearm_timer(struct qemu_alarm_timer *t);
>  
> +#endif
> +
> +#ifdef __linux__
> +
>  static int hpet_start_timer(struct qemu_alarm_timer *t);
>  static void hpet_stop_timer(struct qemu_alarm_timer *t);
>  
> @@ -1001,9 +1005,11 @@
>  
>  static struct qemu_alarm_timer alarm_timers[] = {
>  #ifndef _WIN32
> -#ifdef __linux__
> +#ifdef HAVE_POSIX_TIMER
>      {"dynticks", ALARM_FLAG_DYNTICKS, dynticks_start_timer,
>       dynticks_stop_timer, dynticks_rearm_timer, NULL},
> +#endif
> +#ifdef __linux__
>      /* HPET - if available - is preferred */
>      {"hpet", 0, hpet_start_timer, hpet_stop_timer, NULL, NULL},
>      /* ...otherwise try RTC */
> @@ -1361,7 +1367,7 @@
>      return delta;
>  }
>  
> -#if defined(__linux__) || defined(_WIN32)
> +#if defined(HAVE_POSIX_TIMER) || defined(_WIN32)
>  static uint64_t qemu_next_deadline_dyntick(void)
>  {
>      int64_t delta;
> @@ -1506,6 +1512,10 @@
>      close(rtc_fd);
>  }
>  
> +#endif /* defined(__linux__) */
> +
> +#ifdef HAVE_POSIX_TIMER
> +
>  static int dynticks_start_timer(struct qemu_alarm_timer *t)
>  {
>      struct sigevent ev;
> @@ -1577,7 +1587,7 @@
>      }
>  }
>  
> -#endif /* defined(__linux__) */
> +#endif /* defined(HAVE_POSIX_TIMER) */
>  
>  static int unix_start_timer(struct qemu_alarm_timer *t)
>  {
>
>
>   

[Qemu-devel] SCSI emulation not recognised with Windows Web Server 2008 guest

[Jamie Lokier]

Juergen Lock wrote:
> (I tested dd bs=64k count=500 </dev/vda >/dev/null and
> similar with a raw image, both scsi and virtio were always faster than ide.)

On a related note, I tried using KVM's SCSI with Windows Web Server
2008, and at install time it didn't recognise the SCSI device, asking
for a driver disk.  So I had to use IDE.  Anyone had any better luck
with Windows and SCSI?  Was this device supported by older versions of
Windows?

On virtio, just wondering if anyone's interested in writing Windows
virtio block drivers?

Cheers,
-- Jamie

Re: [Qemu-devel] SCSI emulation not recognised with Windows Web Server 2008 guest

[Dor Laor]

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

Jamie Lokier wrote:
> Juergen Lock wrote:
>   
>> (I tested dd bs=64k count=500 </dev/vda >/dev/null and
>> similar with a raw image, both scsi and virtio were always faster than ide.)
>>     
>
> On a related note, I tried using KVM's SCSI with Windows Web Server
> 2008, and at install time it didn't recognise the SCSI device, asking
> for a driver disk.  So I had to use IDE.  Anyone had any better luck
> with Windows and SCSI?  Was this device supported by older versions of
> Windows?
>
>   
Yes it was. I wonder if there is no win2008 driver?
> On virtio, just wondering if anyone's interested in writing Windows
> virtio block drivers?
>
>   
We'll write one. It will take a while.
> Cheers,
> -- Jamie
>
>
>   


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

Re: [Qemu-devel] testing qemu svn r5890 on FreeBSD - virtio, and a patch enabling -clock dynticks

[Juergen Lock]

In article <493B35AB.1050301@codemonkey.ws> you write:
>Juergen Lock wrote:
>> Hi!
>>
>>  Jung-uk Kim sent me a patch to enable -clock dynticks on FreeBSD hosts
>> (the configure check is mine, only FreeBSD >= 7.x has posix timers that
>> this uses), I'll append it below.
>>
>>  This is the experimental qemu-devel port update I used:
>> 	http://people.freebsd.org/~nox/qemu/qemu-devel-20081206.patch
>> As already mentioned I had to add a missing `#include <sys/uio.h>'
>> (files/patch-qemu-common.h), as also posted here:
>> 	http://lists.gnu.org/archive/html/qemu-devel/2008-12/msg00216.html
>>
>>  I only had one (type of) guest that actually had virtio drivers (three
>> versions of sidux isos), and the speed difference between virtio-blk and
>> scsi was small.  (I tested dd bs=64k count=500 </dev/vda >/dev/null and
>> similar with a raw image, both scsi and virtio were always faster than ide.)
>> I noted tho that even virtio there was not half as fast as ide (and scsi)
>> on KNOPPIX_V5.3.1DVD-2008-03-26-EN.iso, so either overhead has increased
>> greatly from 2.6.24.4 to 2.6.26, or this has something to do with
>> the sidux kernel using CONFIG_NO_HZ and the Knoppix one (apparently) not
>> and qemu (possibly, I also suspected that with the usb slowness) not
>> handling CONFIG_NO_HZ guests too well.  scsi on a FreeBSD
>> 7.1-BETA-i386-livefs.iso guest btw was even yet (noticeably) faster than
>> on the Knoppix iso.  It will be interesting how virtio-net will fare once
>> that gets committed...
>>   
>
>I don't have much experience with perf benchmarking and TCG.  TCG may 
>has interesting side effects.  For instance, it's more expensive to do 
>things in the guest instead of the host so the emulation overhead of 
>IDE/SCSI shouldn't matter much.
>
Actually most of those tests were with -kernel-kqemu sice that is what
I usually run linux guests with.

>A straight dd test is not the best test BTW.  If you want to measure 
>performance, you should use O_DIRECT in the guest (iflag=direct)

 Hmm, how many guest processes will use that?  Or is that what
fses end up doing when the guest does things like, say, cp'ing files
around?

> and 
>probably O_DIRECT in the host (cache=none).

 Ok, will do next time...

 Thanx,
	Juergen

Re: [Qemu-devel] usb slowness again (was: testing qemu svn r5890 on FreeBSD - virtio, and a patch enabling -clock dynticks)

[andrzej zaborowski]

2008/12/6 Juergen Lock <nox@jelal.kn-bremen.de>:
> On Sat, Dec 06, 2008 at 11:09:06PM +0100, Juergen Lock wrote:
>> Hi!
>>
>>  Jung-uk Kim sent me a patch to enable -clock dynticks on FreeBSD hosts
>> (the configure check is mine, only FreeBSD >= 7.x has posix timers that
>> this uses), I'll append it below.
>>
>>  This is the experimental qemu-devel port update I used:
>>       http://people.freebsd.org/~nox/qemu/qemu-devel-20081206.patch
>> As already mentioned I had to add a missing `#include <sys/uio.h>'
>> (files/patch-qemu-common.h), as also posted here:
>>       http://lists.gnu.org/archive/html/qemu-devel/2008-12/msg00216.html
>>
>>  I only had one (type of) guest that actually had virtio drivers (three
>> versions of sidux isos), and the speed difference between virtio-blk and
>> scsi was small.  (I tested dd bs=64k count=500 </dev/vda >/dev/null and
>> similar with a raw image, both scsi and virtio were always faster than ide.)
>> I noted tho that even virtio there was not half as fast as ide (and scsi)
>> on KNOPPIX_V5.3.1DVD-2008-03-26-EN.iso, so either overhead has increased
>> greatly from 2.6.24.4 to 2.6.26, or this has something to do with
>> the sidux kernel using CONFIG_NO_HZ and the Knoppix one (apparently) not
>> and qemu (possibly, I also suspected that with the usb slowness) not
>> handling CONFIG_NO_HZ guests too well.  [...]
>
> Well I just tried -usb -usbdevice net:vlan=1 -net user,vlan=1 with the
> Knoppix iso and got the same thruput (< 40 K/s) for wget on a local
> file than I got with sidux.  So its probably not CONFIG_NO_HZ, at least
> not the usb slowness.

I'm wondering if it's worth reverting the USB overhaul patches until
someone finds time to investigate it.  From my point of view it makes
usb emulation hardly usable, but there are also improvements brought
by these patches (mainly with passthrough).

Cheers