Date: Sun, 18 May 2008 18:16:21 -0400 From: Todd Wasson <tsw5@duke.edu> To: Juergen Lock <nox@jelal.kn-bremen.de> Cc: freebsd-emulation@freebsd.org Subject: Re: kqemu locking my machine hard on amd64 smp, with most recent patches Message-ID: <F1739BAD-038D-4D7D-96D0-FD1E84A9E72B@duke.edu> In-Reply-To: <20080518142427.GA20876@saturn.kn-bremen.de> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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? 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? 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. Todd On May 18, 2008, at 10:24 AM, Juergen Lock wrote: > On Fri, May 16, 2008 at 06:07:32PM -0400, Todd Wasson wrote: >> Using -m 256 doesn't help, though interestingly 1.3.0.p11_5 crashes >> (but >> doesn't take down the machine) with -m 1536 but is fine with -m 256. >> 1.3.0.p11_6 hangs the machine regardless, though. >> >> I haven't been using -soundhw at all recently, but yes, I do >> actually have >> sound on the host. >> >> Lowering hw.physmem to 2GB and using -m 256 still results in a hang. >> >> I'm going to keep these and try the max_locked_pages changes that >> Bakul >> Shah suggested. I'll post the results to the list. >> >> Thanks again. > > OK can you try the following kernel patch with the latest kqemu > (also at > http://people.freebsd.org/~nox/qemu/patch-sys-amd64-seperate-gdt.txt > - untested because my amd64 smp box is in the middle of a > portupgrade that > was long overdue...) > > Index: src/sys/amd64/amd64/mp_machdep.c > =================================================================== > RCS file: /home/ncvs/src/sys/amd64/amd64/mp_machdep.c,v > retrieving revision 1.287.2.2 > diff -u -p -u -r1.287.2.2 mp_machdep.c > --- src/sys/amd64/amd64/mp_machdep.c 28 Nov 2007 23:24:06 -0000 > 1.287.2.2 > +++ src/sys/amd64/amd64/mp_machdep.c 18 May 2008 13:45:32 -0000 > @@ -457,10 +457,18 @@ init_secondary(void) > common_tss[cpu].tss_iobase = sizeof(struct amd64tss); > common_tss[cpu].tss_ist1 = (long)&doublefault_stack[PAGE_SIZE]; > > + /* Use a seperate gdt for each cpu because the tss differs > + * This avoids complications for e.g. virtualization software > + * that needs to reload the task register and otherwise would > + * then end up using the last cpu's tss on others > + */ > + bcopy(&gdt[0], &gdt[NGDT * cpu], NGDT * sizeof(gdt[0])); > + > gdt_segs[GPROC0_SEL].ssd_base = (long) &common_tss[cpu]; > ssdtosyssd(&gdt_segs[GPROC0_SEL], > - (struct system_segment_descriptor *)&gdt[GPROC0_SEL]); > + (struct system_segment_descriptor *)&gdt[NGDT * cpu + > GPROC0_SEL]); > > + r_gdt.rd_base = (long) &gdt[NGDT * cpu]; > lgdt(&r_gdt); /* does magic intra-segment return */ > > /* Get per-cpu data */
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F1739BAD-038D-4D7D-96D0-FD1E84A9E72B>