1
0
mirror of https://git.FreeBSD.org/ports.git synced 2025-01-23 09:10:43 +00:00

- Welcome emulators/qemu-devel ppc host support! :) [1]

- Attempt to make the pkg-message.s a little more readable. [2]
- Bump PORTREVISIONs.

Submitted by:	Andreas Tobler <andreast@fgznet.ch> [1]
Submitted by:	wkoszek [2]  (with modifications)
This commit is contained in:
Juergen Lock 2010-02-08 22:19:29 +00:00
parent e877f1f8ad
commit 2a658a958c
Notes: svn2git 2021-03-31 03:12:20 +00:00
svn path=/head/; revision=249464
9 changed files with 514 additions and 278 deletions

View File

@ -7,7 +7,7 @@
PORTNAME= qemu
PORTVERSION= 0.12.2
PORTREVISION= 1
PORTREVISION= 2
CATEGORIES= emulators
MASTER_SITES= ${MASTER_SITE_SAVANNAH}:release \
${MASTER_SITE_LOCAL}:snapshot \
@ -26,7 +26,7 @@ USE_PERL5= yes
PATCH_STRIP= -p1
MAKE_ENV+= BSD_MAKE="${MAKE}" LDFLAGS="${LDFLAGS}"
MAN1= qemu.1 qemu-img.1
ONLY_FOR_ARCHS= amd64 i386
ONLY_FOR_ARCHS= amd64 i386 powerpc
CONFLICTS= qemu-[0-9]*
MAKE_JOBS_SAFE= yes
@ -87,12 +87,29 @@ BUILD_DEPENDS+= texi2html:${PORTSDIR}/textproc/texi2html
MAKE_ARGS+= ARCH=x86_64
.endif
.if ${ARCH} == "powerpc"
MAKE_ARGS+= ARCH=ppc
.endif
pre-patch:
@for A in ${ONLY_FOR_ARCHS}; do \
${MKDIR} ${WRKSRC}/bsd/$$A; \
done
post-patch:
.if ${ARCH} == "powerpc"
.if ${OSVERSION} < 800030
# These OSVERSION don't have all the needed long double fns in their
# libc so just disable 80 bit floats completely.
@cd ${WRKSRC} && ${PATCH} --quiet -R ${PATCH_STRIP} < ${FILESDIR}/patch-libmath_FreeBSD-version
@cd ${WRKSRC} && ${PATCH} --quiet -R ${PATCH_STRIP} < ${FILESDIR}/patch-fbsd
.else
# ...else we only need to disable the libmath build. (since its
# x86-specific.)
@cd ${WRKSRC} && ${PATCH} --quiet < ${FILESDIR}/revert-fbsd-libmath-patch
.endif
.endif
.if defined(WITH_RTL8139_TIMER)
@cd ${WRKSRC} && ${PATCH} --quiet < ${FILESDIR}/rtl8139-re-patch
.endif

View File

@ -0,0 +1,26 @@
--- a/cache-utils.c
+++ b/cache-utils.c
@@ -57,6 +57,23 @@
}
#endif
+#ifdef __FreeBSD__
+#include <stdio.h>
+#include <sys/types.h>
+#include <sys/sysctl.h>
+
+static void ppc_init_cacheline_sizes(void)
+{
+ size_t len = 4;
+ unsigned cacheline;
+
+ sysctlbyname ("machdep.cacheline_size", &cacheline, &len, NULL, 0);
+
+ qemu_cache_conf.dcache_bsize = cacheline;
+ qemu_cache_conf.icache_bsize = cacheline;
+}
+#endif
+
#ifdef __linux__
void qemu_cache_utils_init(char **envp)
{

View File

@ -0,0 +1,35 @@
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -933,6 +933,20 @@
# define TRAP_sig(context) REG_sig(trap, context)
#endif /* linux */
+#ifdef __FreeBSD__
+#include <ucontext.h>
+# define IAR_sig(context) ((context)->uc_mcontext.mc_srr0)
+# define MSR_sig(context) ((context)->uc_mcontext.mc_srr1)
+# define CTR_sig(context) ((context)->uc_mcontext.mc_ctr)
+# define XER_sig(context) ((context)->uc_mcontext.mc_xer)
+# define LR_sig(context) ((context)->uc_mcontext.mc_lr)
+# define CR_sig(context) ((context)->uc_mcontext.mc_cr)
+/* Exception Registers access */
+# define DAR_sig(context) ((context)->uc_mcontext.mc_dar)
+# define DSISR_sig(context) ((context)->uc_mcontext.mc_dsisr)
+# define TRAP_sig(context) ((context)->uc_mcontext.mc_exc)
+#endif /* __FreeBSD__ */
+
#ifdef __APPLE__
# include <sys/ucontext.h>
typedef struct ucontext SIGCONTEXT;
@@ -962,7 +976,11 @@
void *puc)
{
siginfo_t *info = pinfo;
+#if defined (__FreeBSD__)
+ ucontext_t *uc = puc;
+#else
struct ucontext *uc = puc;
+#endif
unsigned long pc;
int is_write;

View File

@ -0,0 +1,77 @@
--- a/ppc.ld
+++ b/ppc.ld
@@ -79,36 +79,34 @@
}
.sbss2 : { *(.sbss2 .sbss2.* .gnu.linkonce.sb2.*) }
.eh_frame_hdr : { *(.eh_frame_hdr) }
- .eh_frame : ONLY_IF_RO { KEEP (*(.eh_frame)) }
- .gcc_except_table : ONLY_IF_RO { *(.gcc_except_table .gcc_except_table.*) }
/* Adjust the address for the data segment. We want to adjust up to
the same address within the page on the next page up. */
. = ALIGN (0x10000) - ((0x10000 - .) & (0x10000 - 1)); . = DATA_SEGMENT_ALIGN (0x10000, 0x1000);
/* Exception handling */
- .eh_frame : ONLY_IF_RW { KEEP (*(.eh_frame)) }
- .gcc_except_table : ONLY_IF_RW { *(.gcc_except_table .gcc_except_table.*) }
+ .eh_frame : { KEEP (*(.eh_frame)) }
+ .gcc_except_table : { *(.gcc_except_table .gcc_except_table.*) }
/* Thread Local Storage sections */
.tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) }
.tbss : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) }
.preinit_array :
{
- PROVIDE_HIDDEN (__preinit_array_start = .);
+ PROVIDE (__preinit_array_start = .);
KEEP (*(.preinit_array))
- PROVIDE_HIDDEN (__preinit_array_end = .);
+ PROVIDE (__preinit_array_end = .);
}
.init_array :
{
- PROVIDE_HIDDEN (__init_array_start = .);
+ PROVIDE (__init_array_start = .);
KEEP (*(SORT(.init_array.*)))
KEEP (*(.init_array))
- PROVIDE_HIDDEN (__init_array_end = .);
+ PROVIDE(__init_array_end = .);
}
.fini_array :
{
- PROVIDE_HIDDEN (__fini_array_start = .);
+ PROVIDE (__fini_array_start = .);
KEEP (*(.fini_array))
KEEP (*(SORT(.fini_array.*)))
- PROVIDE_HIDDEN (__fini_array_end = .);
+ PROVIDE (__fini_array_end = .);
}
.ctors :
{
@@ -142,9 +140,8 @@
.got1 : { *(.got1) }
.got2 : { *(.got2) }
.dynamic : { *(.dynamic) }
- .got : SPECIAL { *(.got) }
- . = DATA_SEGMENT_RELRO_END (0, .);
- .plt : SPECIAL { *(.plt) }
+ .got : { *(.got) }
+ .plt : { *(.plt) }
.data :
{
*(.data .data.* .gnu.linkonce.d.*)
@@ -152,7 +149,7 @@
SORT(CONSTRUCTORS)
}
.data1 : { *(.data1) }
- .got : SPECIAL { *(.got) }
+ .got : { *(.got) }
/* We want the small data sections together, so single-instruction offsets
can access them all, and initialized data all before uninitialized, so
we can shorten the on-disk segment size. */
@@ -171,7 +168,7 @@
*(.scommon)
PROVIDE (__sbss_end = .); PROVIDE (___sbss_end = .);
}
- .plt : SPECIAL { *(.plt) }
+ .plt : { *(.plt) }
.bss :
{
*(.dynbss)

View File

@ -0,0 +1,11 @@
--- a/tcg/ppc/tcg-target.h
+++ b/tcg/ppc/tcg-target.h
@@ -69,7 +69,7 @@
#define TCG_TARGET_CALL_STACK_OFFSET 24
#elif defined _AIX
#define TCG_TARGET_CALL_STACK_OFFSET 52
-#elif defined __linux__
+#elif defined __linux__ || defined __FreeBSD__
#define TCG_TARGET_CALL_ALIGN_ARGS 1
#define TCG_TARGET_CALL_STACK_OFFSET 8
#else

View File

@ -0,0 +1,14 @@
--- Makefile.orig 2010-02-06 20:59:24.000000000 +0100
+++ Makefile 2010-02-06 21:00:17.000000000 +0100
@@ -62,10 +62,7 @@
-include config-all-devices.mak
-build-all: $(DOCS) $(TOOLS) bsd/libmath.a recurse-all
-
-bsd/libmath.a:
- ( cd bsd ; unset MAKEFLAGS ; $(BSD_MAKE) CC=$(CC) )
+build-all: $(DOCS) $(TOOLS) recurse-all
config-host.h: config-host.h-timestamp
config-host.h-timestamp: config-host.mak

View File

@ -1,141 +1,169 @@
====
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 it 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.)
- 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.)
- 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.
- 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.
- (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:
- 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.
- 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.
- (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 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.
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 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:
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
)
====
)

View File

@ -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/

View File

@ -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.