[
{ type: install
  message: <<EOM
FreeBSD host notes
==================

- Needs to set net.link.tap.user_open sysctl in order to use /dev/tap*
  networking as non-root.  Don't forget to adjust device node permissions in
  /etc/devfs.rules.

- Expect timer problems when guest kernel HZ is > hosts.  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.)

- The -smb option (smb-export local dir to guest using the default
  slirp networking) needs the samba port/package installed
  in addition to qemu. (SAMBA knob.)

- If you want to use usb devices connected to the host in the guest
  yot can use usbredir over the network (see below); 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:

	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.  [Not sure
  if this still applies to the new libusb host code used on recent
  10-current.]

- 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.  [Looks like this is fixed in recent
  FreeBSD guest versions.]

- If you build qemu wihout SDL and then get crashes running it try passing it
  -nographic.  This should probably be default in that case...

- 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

	cp /boot/pxeboot pxeboot-qemu && chmod +w pxeboot-qemu && echo >>pxeboot-qemu

  and then use pxeboot-qemu.  Actually you need recent 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:

	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.

- (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; and meanwhile there
  also is the new qed format - I don't know how stable that one is.]

- (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 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.)

EOM
}
]