kqemu locking my machine hard on amd64 smp, with most recent patches

Juergen Lock nox at jelal.kn-bremen.de
Sun May 18 23:07:48 UTC 2008


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


More information about the freebsd-emulation mailing list