Date: Mon, 19 May 2008 01:04:19 +0200 From: Juergen Lock <nox@jelal.kn-bremen.de> To: Todd Wasson <tsw5@duke.edu> Cc: freebsd-emulation@freebsd.org Subject: Re: kqemu locking my machine hard on amd64 smp, with most recent patches Message-ID: <20080518230419.GA48991@saturn.kn-bremen.de> In-Reply-To: <F1739BAD-038D-4D7D-96D0-FD1E84A9E72B@duke.edu> References: <20080515080948.3B1F15B47@mail.bitblocks.com> <200805152323.m4FNNO7H017348@saturn.kn-bremen.de> <E5773BA5-1BE8-4847-A581-43F035E9DA3B@duke.edu> <20080518142427.GA20876@saturn.kn-bremen.de> <F1739BAD-038D-4D7D-96D0-FD1E84A9E72B@duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 18, 2008 at 06:16:21PM -0400, Todd Wasson wrote: > Hi Juergen. That patch seems to have fixed the problem for me, as verified > with both kqemu-kmod-1.3.0.p11_6 and kqemu-kmod-1.3.0.p11_7. However, I'm > somewhat uneasy about using this patch on my system long-term, since it > hasn't been rigorously tested. Are there putative implications of this > patch with other software that I should be aware of? Well, `regular' software shouldn't care about the gdt being shared or not id say, this is a very lowlevel implementation detail that this patch changes. (The gdt also isn't shared on i386, fwiw.) > Is this kernel patch > considered to be the final fix, or just a band-aid until the underlying > cause can be addressed from within kqemu alone? > No actually I'd call this kernel patch a more `proper' fix, what kqemu now does is move the gdts of all but the first cpu after the fact (if they are shared), this patch sets them up seperate from the beginning. (Actually I updated the patch after the original post, but the changes are only cosmetic.) I can't speak for the src people tho, so I don't know whether they may deem it commit-worthy later, but using it _should_ be safe. > Thanks again for your help with this. On a side note, what is the status > of kqemu kernel mode support on SMP amd64 (i.e. qemu-system-x86_64 > -kernel-kqemu)? Even though kqemu is more or less working for me now, it's > still quite slow and I presume this to be why. -kernel-kqemu is just less well debugged on amd64 than on i386, it may still work with some guests. (The problem with kqemu is it gets kinda neglected these days by the linux guys since they have all these other virtualization solutions now that people seem to like better...) Juergen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080518230419.GA48991>