From owner-freebsd-emulation@FreeBSD.ORG Sun May 18 22:16:23 2008 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B9341065671 for ; Sun, 18 May 2008 22:16:23 +0000 (UTC) (envelope-from tsw5@duke.edu) Received: from smtp.duke.edu (smtp-04.oit.duke.edu [152.3.174.85]) by mx1.freebsd.org (Postfix) with ESMTP id 0A16B8FC1A for ; Sun, 18 May 2008 22:16:22 +0000 (UTC) (envelope-from tsw5@duke.edu) Received: from smtp.duke.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 475C4358BD7; Sun, 18 May 2008 18:16:22 -0400 (EDT) Received: from avenue.wintermute (cpe-076-182-024-090.nc.res.rr.com [76.182.24.90]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.duke.edu (Postfix) with ESMTP id 014D5358AC4; Sun, 18 May 2008 18:16:21 -0400 (EDT) Message-Id: From: Todd Wasson To: Juergen Lock In-Reply-To: <20080518142427.GA20876@saturn.kn-bremen.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sun, 18 May 2008 18:16:21 -0400 References: <20080515080948.3B1F15B47@mail.bitblocks.com> <200805152323.m4FNNO7H017348@saturn.kn-bremen.de> <20080518142427.GA20876@saturn.kn-bremen.de> X-Mailer: Apple Mail (2.919.2) X-PMX-Version: 5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.5.18.150108 Cc: freebsd-emulation@freebsd.org Subject: Re: kqemu locking my machine hard on amd64 smp, with most recent patches X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2008 22:16:23 -0000 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 */