2 files changed, 175 insertions, 147 deletions

diff --git a/emulators/qemu/Makefile b/emulators/qemu/Makefile
index 1e5f983ce338..9278dd1c89f8 100644
--- a/emulators/qemu/Makefile
+++ b/emulators/qemu/Makefile
@@ -7,7 +7,7 @@
 
 PORTNAME=	qemu
 PORTVERSION=	0.11.1
-PORTREVISION=	1
+PORTREVISION=	2
 CATEGORIES=	emulators
 MASTER_SITES=	${MASTER_SITE_SAVANNAH} \
 		http://bellard.org/qemu/
diff --git a/emulators/qemu/pkg-message b/emulators/qemu/pkg-message
index 6e35e73f7698..64cdd9b427c2 100644
--- a/emulators/qemu/pkg-message
+++ b/emulators/qemu/pkg-message
@@ -1,158 +1,186 @@
-====
-FreeBSD host notes:
-- needs to run as root in order to use /dev/tap* networking (why?)
-(actually RELENG_6 and above now has a sysctl net.link.tap.user_open
-to allow users to use it too.  don't forget to adjust device node
-permissions in /etc/devfs.rules.)
-- slirp (usermode networking) is fixed now in cvs, on FreeSBIE 1.0 guests
-you still have to manually do:
-	echo nameserver 10.0.2.3 >/etc/resolv.conf
-but i've been told that that's normal. (fixed on FreeSBIE 1.1.)
-and you have to wait a bit for dhclient to do its thing; traffic to
-address 10.0.2.2 is routed to 127.1 on the host.
-- expect timer problems when guest kernel HZ is > hosts,
-for example time sleep 1 takes 49 seconds and booting sleeps for
-minutes at the acd0 probe with a FreeSBIE 1.0 guest, thats because
-its kernel is built with HZ=5000, and FreeBSD's default is 100...
-(no longer a problem with FreeSBIE 1.1.)  The linux 2.6 kernel uses
-1000 by default btw. (changed to 250 later, and recent linux kernels now
-no longer have a fixed HZ, aka `tickless kernel'...)  Enabling /dev/rtc
-doesn't seem to help either (not included since it needs a patch to
-emulators/rtc.)
-- update: the above problem has gotten worse with FreeBSD guests
-somewhere before 8.0, mainly since the kernel now usually wants
-double or even quadruple number of timer irqs compared to HZ if it
-detects an apic (and at least early versions of FreeBSD 8 had a bug that
-essentially halved qemu's clock rate too); the only reason you usually
-don't see symptoms of this with FreeBSD 8 guests is they automatically
-reduce their HZ to 100 when running in a VM while the default for the
-host kernel is still HZ=1000.  workarounds:  for i386 guests you can
-disable the apic in the guest by setting
+FreeBSD host notes
+==================
+
+- Needs to run as root in order to use /dev/tap* networking (why?) (actually
+  RELENG_6 and above now has a sysctl net.link.tap.user_open to allow users to
+  use it too.  Don't forget to adjust device node permissions in
+  /etc/devfs.rules.)
+
+- slirp (usermode networking) is fixed now in cvs, on FreeSBIE 1.0 guests you
+  still have to manually do: echo nameserver 10.0.2.3 >/etc/resolv.conf but
+  i've been told that that's normal.  (fixed on FreeSBIE 1.1.) And you have
+  to wait a bit for dhclient to do its thing; traffic to address 10.0.2.2 is
+  routed to 127.1 on the host.
+
+- Expect timer problems when guest kernel HZ is > hosts, for example time
+  sleep 1 takes 49 seconds and booting sleeps for minutes at the acd0 probe
+  with a FreeSBIE 1.0 guest, thats because its kernel is built with HZ=5000,
+  and FreeBSD's default is 100...  (no longer a problem with FreeSBIE 1.1.)
+  The linux 2.6 kernel uses 1000 by default btw.  (changed to 250 later, and
+  recent linux kernels now no longer have a fixed HZ, aka `tickless
+  kernel'...)  Enabling /dev/rtc doesn't seem to help either (not included
+  since it needs a patch to emulators/rtc.)
+
+- update: the above problem has gotten worse with FreeBSD guests somewhere
+  before 8.0, mainly since the kernel now usually wants double or even
+  quadruple number of timer irqs compared to HZ if it detects an apic (and at
+  least early versions of FreeBSD 8 had a bug that essentially halved qemu's
+  clock rate too); the only reason you usually don't see symptoms of this with
+  FreeBSD 8 guests is they automatically reduce their HZ to 100 when running
+  in a VM while the default for the host kernel is still HZ=1000.
+  workarounds:  for i386 guests you can disable the apic in the guest by
+  setting
+
 	hint.apic.0.disabled=1
-in loader.conf(5) (or manually at the loader prompt), otherwise the
-only thing you can do is either reduce the guest's HZ to, say, 100
-by setting e.g.
+
+  in loader.conf(5) (or manually at the loader prompt), otherwise the only thing
+  you can do is either reduce the guest's HZ to, say, 100 by setting e.g.
+
 	kern.hz="100"
-from the loader as above (which usually is a good idea in a VM anyway
-and FreeBSD 8 now does by itself as mentioned), or if that's not
-possible increase the host's HZ to 2000 or even 4000 from the loader
-in the same way.
-- the -smb option (smb-export local dir to guest) needs the net/samba3
-port/package installed in addition to qemu.
-- if you want to use usb devices connected to the host in the guest
-(usb_add host:... monitor command; this doesn't work on FreeBSD 8 and
--current atm because of the new usb stack - help updating the usb-bsd.c
-code is more than welcome here!) you need to make sure the host isn't
-claiming them, e.g. for umass devices (like memory sticks or external
-harddrives) make sure umass isn't in the kernel (you can then still
-load it as a kld when needed), also unless you are running qemu as
-root you then need to fix permissions for /dev/ugen* device nodes:
-if you are on 5.x or later (devfs) put a rule in /etc/devfs.rules,
-activate it in /etc/rc.conf and run /etc/rc.d/devfs restart.
-example devfs.rules:
+
+  from the loader as above (which usually is a good idea in a VM anyway and
+  FreeBSD 8 now does by itself as mentioned), or if that's not possible
+  increase the host's HZ to 2000 or even 4000 from the loader in the same way.
+
+- The -smb option (smb-export local dir to guest) needs the net/samba3
+  port/package installed in addition to qemu.
+
+- If you want to use usb devices connected to the host in the guest
+  (usb_add host:... monitor command; this doesn't work on FreeBSD 8 and
+  -current atm because of the new usb stack - help updating the usb-bsd.c code
+  is more than welcome here!) you need to make sure the host isn't claiming
+  them, e.g. for umass devices (like memory sticks or external harddrives)
+  make sure umass isn't in the kernel (you can then still load it as a kld
+  when needed), also unless you are running qemu as root you then need to fix
+  permissions for /dev/ugen* device nodes: if you are on 5.x or later (devfs)
+  put a rule in /etc/devfs.rules, activate it in /etc/rc.conf and run
+  /etc/rc.d/devfs restart.  Example devfs.rules:
+
 	[ugen_ruleset=20]
 	add path 'ugen*' mode 660 group operator
-corresponding rc.conf line:
+
+  corresponding rc.conf line:
+
 	devfs_system_ruleset="ugen_ruleset"
-- still usb: since the hub is no longer attached to the uchi controller
-and the wakeup mechanism, resume interrupt is not implemented yet linux
-guests will suspend the bus, i.e. they wont see devices usb_add'ed after
-its (linux') uhci module got loaded.  workaround: either add devices
-before linux loads the module or rmmod and modprobe it afterwards.
-- to avoid panics or non-working re(4) nics with FreeBSD guests if you
-use qemu -net nic,model=rtl8139 -net user or tap ... enable the emulated
-rtl8139 timer by building the port with RTL8139_TIMER enabled.
-(the rtl8139c+ that model=rtl8139 emulates needs less cpu than qemu's
-default ne2k nic which is driven by ed(4), it has not been made default
-only because it may not work with all guests yet.  btw qemu now also can
-emulate a few intel eepro100 and e1000 nics which seem to be a tad more
-efficient even, and at least i82557b and e1000 work without tweaks for
-FreeBSD guests - driven by fxp(4) and em(4) repectively - and Linux
-guests too.)
-- if you get repeated `atapi_poll called!' console messages with FreeBSD
-guests or other weird cdrom problems then thats probably because the guest
-has atapicam loaded, which for reasons still to be determined has problems
-with qemu's now by default enabled cdrom dma.  You can build the port with
-CDROM_DMA disabled to disable it.
-- if you build qemu wihout SDL and then get crashes running it try
-passing it -nographic.  This should probably be default in that case...
-- perhaps it should be noted that if you want to use qemu with -m 512
-or larger on 6.x/i386 hosts you need to increase the kern.maxdsiz tunable
-in loader.conf(5) since the default is 512 MB, and qemu needs memory for
-itself also.  (7.0 and up now use jemalloc which uses mmap(2) and
-isn't affected by kern.maxdsiz anymore.)
-- if you use kqemu make sure your kqemu.ko is always in sync with your
-kernel (like with any kld installed outside of base), i.e.  rebuild its
-port whenever you update the kernel - especially if you are switching
-branches or are following a -stable or even -current branch!
-- you can enable autoloading of kqemu at boot by adding a line
+
+- Still usb: since the hub is no longer attached to the uchi controller and
+  the wakeup mechanism, resume interrupt is not implemented yet linux guests
+  will suspend the bus, i.e. they wont see devices usb_add'ed after its
+  (linux') uhci module got loaded.  Workaround: either add devices before
+  linux loads the module or rmmod and modprobe it afterwards.
+
+- To avoid panics or non-working re(4) nics with FreeBSD guests if you use
+  qemu -net nic,model=rtl8139 -net user or tap ... enable the emulated rtl8139
+  timer by building the port with RTL8139_TIMER enabled.   (The rtl8139c+ that
+  model=rtl8139 emulates needs less cpu than qemu's default ne2k nic which is
+  driven by ed(4), it has not been made default only because it may not work
+  with all guests yet.  Btw qemu now also can emulate a few intel eepro100 and
+  e1000 nics which seem to be a tad more efficient even, and at least i82557b
+  and e1000 work without tweaks for FreeBSD guests - driven by fxp(4) and
+  em(4) repectively - and Linux guests too.)
+
+- If you get repeated `atapi_poll called!' console messages with FreeBSD
+  guests or other weird cdrom problems then thats probably because the guest
+  has atapicam loaded, which for reasons still to be determined has problems
+  with qemu's now by default enabled cdrom dma.  You can build the port with
+  CDROM_DMA disabled to disable it.
+
+- If you build qemu wihout SDL and then get crashes running it try passing it
+  -nographic.  This should probably be default in that case...
+
+- Perhaps it should be noted that if you want to use qemu with -m 512 or
+  larger on 6.x/i386 hosts you need to increase the kern.maxdsiz tunable in
+  loader.conf(5) since the default is 512 MB, and qemu needs memory for itself
+  also.  (7.0 and up now use jemalloc which uses mmap(2) and isn't affected by
+  kern.maxdsiz anymore.)
+
+- If you use kqemu make sure your kqemu.ko is always in sync with your kernel
+  (like with any kld installed outside of base), i.e. rebuild its port
+  whenever you update the kernel - especially if you are switching branches or
+  are following a -stable or even -current branch!
+
+- You can enable autoloading of kqemu at boot by adding a line
+
 	kqemu_enable=YES
-to /etc/rc.conf
-- kqemu liked to panic the host on amd64 SMP until before 1.3.0.p11_6
-(revision 1.25 of /usr/ports/emulators/kqemu-kmod/Makefile), so if your
-host is such you might want to make sure your kqemu-kmod port is new enough.
-(and don't forget to reload it...)
+
+  to /etc/rc.conf
+
 - qemu's network boot roms (-boot n) have a bug when bootfiles sizes are a
-multiple of blksize, if this affects you (like with FreeBSD's /boot/pxeboot)
-you can do like
+  multiple of blksize, if this affects you (like with FreeBSD's /boot/pxeboot)
+  you can do like
+
 	cp /boot/pxeboot pxeboot-qemu && chmod +w pxeboot-qemu && echo >>pxeboot-qemu
-and then use pxeboot-qemu.  Actually you need latest -stable or -current
-btx code (from after 7.0 was released) because of the real mode boot problem,
-so use at least pxeboot from there.  And I just did that for the pxeboot
-extracted out of
+
+  and then use pxeboot-qemu.  Actually you need latest -stable or -current btx
+  code (from after 7.0 was released) because of the real mode boot problem, so
+  use at least pxeboot from there.  And I just did that for the pxeboot
+  extracted out of
+
 	ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/200805/7.0-STABLE-200805-i386-bootonly.iso
-and placed it here:
+
+  and placed it here:
+
 	http://people.freebsd.org/~nox/qemu/pxeboot-qemu
-- if you use slirp (usernet, the default) and want to mount nfs into the
-guest and you are not running qemu as root, then mountd(8) on the exporting
-box needs to be run with -n in order to accept requests from ports >= 1024.
-- unfortunately there can still be guests that don't run correctly with
-kqemu and -kernel-kqemu especially on amd64 - not much you can do about that
-other than help debugging (k)qemu... (well or falling back to unaccellerated
-qemu/using only -enable-kqemu if its that what's causing the problems.
-note however that kqemu now can also be used with the 32 bit qemu even
-on amd64 hosts as of the 20080620 update.)
-- the new (optional) pcap code cannot talk to the host on 6.x because
-the necessary bpf feature (BIOCFEEDBACK) hasn't (yet?) been merged there.
+
+- If you use slirp (usernet, the default) and want to mount nfs into the guest
+  and you are not running qemu as root, then mountd(8) on the exporting box
+  needs to be run with -n in order to accept requests from ports >= 1024.
+
+- Unfortunately there can still be guests that don't run correctly with kqemu
+  and -kernel-kqemu especially on amd64 - not much you can do about that other
+  than help debugging (k)qemu... (well or falling back to unaccellerated
+  qemu/using only -enable-kqemu if its that what's causing the problems.  note
+  however that kqemu now can also be used with the 32 bit qemu even on amd64
+  hosts as of the 20080620 update.)
+
+- The new (optional) pcap code cannot talk to the host on 6.x because the
+  necessary bpf feature (BIOCFEEDBACK) hasn't (yet?) been merged there.
+
 - kqemu passes the host tsc to the guest as-is so depending on your cpu and
-guest you _may_ need to tell the guest to avoid relying on the tsc (notsc
-kernel parameter with linux), or if that doesn't work force qemu onto
-a single cpu by doing e.g. `cpuset -l 0 qemu ..' (see the cpuset(1) manpage
-for details; cpuset isn't avalable before 7.1.  This can only be a problem
-on smp hosts.)
-- (not FreeBSD-specific:) there have been reports of qcow2 corruption with
-(at least) win2k guests on recent kvm (which uses similar qcow2 code than
-qemu now, see this thread:
+  guest you _may_ need to tell the guest to avoid relying on the tsc (notsc
+  kernel parameter with linux), or if that doesn't work force qemu onto a
+  single cpu by doing e.g. `cpuset -l 0 qemu ..' (see the cpuset(1) manpage
+  for details; cpuset isn't avalable before 7.1.  This can only be a problem
+  on smp hosts.)
+
+- (not FreeBSD-specific:) There have been reports of qcow2 corruption with (at
+  least) win2k guests on recent kvm (which uses similar qcow2 code than qemu
+  now, see this thread:
+
 	http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg00713.html -
-the consensus on that thread seems to be that qcow(2) code has always
-been experimental and you should use raw images if you want reliability;
-raw is also usually faster.)  You should be able to migrate existing images
-to raw using qemu-img(1)'s convert function; raw doesn't support advanced
-features like snapshots tho.
-[a few important qcow2 bugfixed have been committed in the meantime so
-this _might_ be less of an issue now.]
-- (also not FreeBSD-specific:)  It is recommended to pass raw images using
-the new -drive syntax, specifying format=raw explicitly in order to avoid
-malicious guests being able to exploit the format autodetection thats
-otherwise getting used.  (Not that you should run malicious guests anyway,
-but this eleminates at least a known attack vector.)
-- qemu now has improved physical cdrom support, but still there still
-is at least one known problem: you need to have the guest eject the disc
-if you want to change it/take it out, or otherwise the guest may continue
-using state (like size) of the old disc.  (You can also do like
-`change ide1-cd0 /dev/acd0' in the monitor after taking out the disc
-if a guest cannot eject it itself.)
-- The default configuration location (qemu-ifup script etc.) has been
-changed from /etc to PREFIX/etc (usually /usr/local/etc).  Move your
-files accordingly.
-- The pcap code (-net nic... -net pcap,ifname=...) should work properly
-now, with only one exception:  Advanced features like TSO used on the host
-interface can cause oversize packets which now do get truncated to avoid
-confusing/panicing guests but of course still will cause retransmissions.
-So if you see slow throughput and `pcap_send: packet size > ..., truncating'
-messages on qemu's tty try disabling TSO etc on the host interface at least
-while using pcap.
-- kqemu still works in the 0.11 branch, but is disabled by default now
-so you'll have to pass -enable-kqemu (or -kernel-kqemu as with the
-previous versions) if you want to use it.
-====
+
+  the consensus on that thread seems to be that qcow(2) code has always been
+  experimental and you should use raw images if you want reliability; raw is
+  also usually faster.)  You should be able to migrate existing images to raw
+  using qemu-img(1)'s convert function; raw doesn't support advanced features
+  like snapshots tho.  [a few important qcow2 bugfixed have been committed in
+  the meantime so this _might_ be less of an issue now.]
+
+- (also not FreeBSD-specific:)  It is recommended to pass raw images using the
+  new -drive syntax, specifying format=raw explicitly in order to avoid
+  malicious guests being able to exploit the format autodetection thats
+  otherwise getting used.  (Not that you should run malicious guests anyway,
+  but this eleminates at least a known attack vector.)
+
+- qemu now has improved physical cdrom support, but still there still is at
+  least one known problem: you need to have the guest eject the disc if you
+  want to change it/take it out, or otherwise the guest may continue using
+  state (like size) of the old disc.  (You can also do like `change ide1-cd0
+  /dev/acd0' in the monitor after taking out the disc if a guest cannot eject
+  it itself.)
+
+- The default configuration location (qemu-ifup script etc.) has been changed
+  from /etc to PREFIX/etc (usually /usr/local/etc).  Move your files
+  accordingly.
+
+- The pcap code (-net nic... -net pcap,ifname=...) should work properly now,
+  with only one exception:  Advanced features like TSO used on the host
+  interface can cause oversize packets which now do get truncated to avoid
+  confusing/panicing guests but of course still will cause retransmissions.
+  So if you see slow throughput and `pcap_send: packet size > ..., truncating'
+  messages on qemu's tty try disabling TSO etc on the host interface at least
+  while using pcap.
+
+- kqemu still works in the 0.11 branch, but is disabled by default now so
+  you'll have to pass -enable-kqemu (or -kernel-kqemu as with the previous
+  versions) if you want to use it.