aboutsummaryrefslogtreecommitdiff
path: root/emulators/qemu/pkg-message
diff options
context:
space:
mode:
authorMuhammad Moinur Rahman <bofh@FreeBSD.org>2015-12-16 14:15:19 +0000
committerMuhammad Moinur Rahman <bofh@FreeBSD.org>2015-12-16 14:15:19 +0000
commitcb11558b75bc84cf6c824c94aad9b343fea1224b (patch)
treeb7fe8a5e75d0b2b53b0fed24f2817e5986b0e7bc /emulators/qemu/pkg-message
parent6e3ef4bb11ee38a266998c4205e4dc1b8e397a01 (diff)
downloadports-cb11558b75bc84cf6c824c94aad9b343fea1224b.tar.gz
ports-cb11558b75bc84cf6c824c94aad9b343fea1224b.zip
Notes
Diffstat (limited to 'emulators/qemu/pkg-message')
-rw-r--r--emulators/qemu/pkg-message102
1 files changed, 52 insertions, 50 deletions
diff --git a/emulators/qemu/pkg-message b/emulators/qemu/pkg-message
index 5567bf0c0529..9292512f5cfe 100644
--- a/emulators/qemu/pkg-message
+++ b/emulators/qemu/pkg-message
@@ -48,15 +48,12 @@ FreeBSD host notes
in addition to qemu. (SAMBA knob.)
- 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:
+ yot need either recent 10-current (not tested yet much) or you 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
@@ -65,21 +62,42 @@ FreeBSD host notes
devfs_system_ruleset="ugen_ruleset"
+- If you want to test the new (in 0.15.0) usb network redirection (USBREDIR
+ option) see this thread by Hans de Goede <hdegoede <at> redhat.com>:
+
+ http://thread.gmane.org/gmane.comp.emulators.qemu/110176/focus=110183
+
+ Quote:
+
+ Example usage:
+
+ 1) Start usbredirserver for a usb device:
+ sudo usbredirserver 045e:0772
+ 2) Start qemu with usb2 support + a chardev talking to usbredirserver +
+ a usb-redir device using this chardev:
+ qemu -usb \
+ -readconfig docs/ich9-ehci-uhci.cfg \
+ -chardev socket,id=usbredirchardev,host=localhost,port=4000 \
+ -device usb-redir,chardev=usbredirchardev,id=usbredirdev ...
+
+ [you would replace docs/ich9-ehci-uhci.cfg with e.g.
+ /usr/local/share/doc/qemu/docs/ich9-ehci-uhci.cfg, but turns out
+ ehci was broken for me here with FreeBSD guests and the previous
+ qemu version at least, I got:
+
+ FETCHENTRY: entry at 22C5484 is of type 2 which is not supported yet
+processing error - resetting ehci HC
+ Assertion failed: (0), function ehci_advance_state, file /data/ports/emulators/qemu-devel/work/qemu-0.15.0/hw/usb-ehci.c, line 2045.
+
+ The new qemu version works better tho.]
+
- 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.)
+ 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
@@ -91,17 +109,6 @@ FreeBSD host notes
- If you build qemu wihout SDL and then get crashes running it try passing it
-nographic. This should probably be default in that case...
-- 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
-
- 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
@@ -123,20 +130,6 @@ FreeBSD host notes
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.)
-
-- 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:
@@ -148,7 +141,8 @@ FreeBSD host notes
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.]
+ 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
@@ -156,7 +150,7 @@ FreeBSD host notes
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
+- 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
@@ -175,6 +169,14 @@ FreeBSD host notes
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.
+- kqemu is no longer supported in qemu upstream after the 0.11 branch
+ was created, which means also not in this version. (Linux has moved
+ on to kvm now for qemu(-like) virtualization needs, so if you want qemu
+ to go faster and don't want to switch to virtualbox or stick to the older
+ emulators/qemu port which is at 0.11.1 atm and as such still supports
+ kqemu you should help getting the FreeBSD kvm port updated and
+ completed:
+
+ http://wiki.freebsd.org/FabioChecconi/PortingLinuxKVMToFreeBSD
+
+ )