Skip site navigation (1)Skip section navigation (2)
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>