Suppose you compiled qemu with kqemu flavor if kqemu is loaded :
1) no kqemu at all : $ qemu -no-kqemu 2) qemu with kqemu in user mode : (in this mode OpenBSD and NetBSD guests will work, thanks to Adrian's patch to kqemu : patches/patch-common_monitor_c) $ qemu 3) qemu with kqemu in kernel mode : (in this mode OpenBSD and NetBSD guests wont work) $ qemu -kernel-kqemu if kqemu is not loaded : which ever command line you type, it will run without kqemu ( 2) 3) will complain but run without kqemu) btw, an ultra-mini benchmark, I gziped the same file and mesured the time it took: 770 seconds OpenBSD host XP guest without kqemu 132 seconds OpenBSD host XP guest with user kqemu 115 seconds OpenBSD host XP guest with kernel kqemu 80 seconds XP native On Mon, Jan 21, 2008 at 02:22:47PM +0100, Hannah Schroeter wrote: > Hi! > > On Mon, Jan 21, 2008 at 12:41:29PM +0100, Antoine Jacoutot wrote: > >On Mon, 21 Jan 2008, Hannah Schroeter wrote: > >>Seems people reported problems with kqemu, so I'm not in favor of > >>dropping the non-kqemu variant. > > >The point is that qemu should work fine with or without kqemu with no > >need of a FLAVOR. > >Even if compiled with support for kqemu, qemu will proceed in software > >mode is the kernel module is not loaded. > > >If this works fine like that, then the non-kqemu variant should be > >dropped. > > Can one, then, also disable kqemu in the kqemu variant of qemu even when > the kqemu kernel module is loaded, e.g. with a command line option? > > E.g. if I'm a non-root user on a box and I've noticed that there's > subtle behavior difference that is bad for me? > > Kind regards, > > Hannah. > >
