Date: Wed, 19 Jan 2011 16:19:06 -0500 From: Jung-uk Kim <jkim@FreeBSD.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r217587 - head/sys/i386/i386 Message-ID: <201101191619.08220.jkim@FreeBSD.org> In-Reply-To: <20110119205513.GC2518@deviant.kiev.zoral.com.ua> References: <201101191709.p0JH97ZD083132@svn.freebsd.org> <201101191311.03440.jkim@FreeBSD.org> <20110119205513.GC2518@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 19 January 2011 03:55 pm, Kostik Belousov wrote: > On Wed, Jan 19, 2011 at 01:11:01PM -0500, Jung-uk Kim wrote: > > On Wednesday 19 January 2011 12:18 pm, Kostik Belousov wrote: > > > On Wed, Jan 19, 2011 at 05:09:07PM +0000, Jung-uk Kim wrote: > > > > Author: jkim > > > > Date: Wed Jan 19 17:09:07 2011 > > > > New Revision: 217587 > > > > URL: http://svn.freebsd.org/changeset/base/217587 > > > > > > > > Log: > > > > Fix yet another fallout from r208833. VM86 BIOS call may > > > > cause page fault when FPU is in use. > > > > > > > > Reported by: Marc UBM Bocklet (ubm dot freebsd at > > > > googlemail dot com) Tested by: b. f. (bf1783 at googlemail > > > > dot com) MFC after: 3 days > > > > > > > > Modified: > > > > head/sys/i386/i386/vm86bios.s > > > > > > > > Modified: head/sys/i386/i386/vm86bios.s > > > > ============================================================= > > > >==== ============= --- head/sys/i386/i386/vm86bios.s Wed Jan > > > > 19 17:04:07 2011 (r217586) +++ > > > > head/sys/i386/i386/vm86bios.s Wed Jan 19 17:09:07 > > > > 2011 (r217587) @@ -73,10 +73,9 @@ > > > > ENTRY(vm86_bioscall) > > > > je 1f /* no curproc/npxproc */ > > > > pushl %edx > > > > movl TD_PCB(%ecx),%ecx > > > > - addl $PCB_SAVEFPU,%ecx > > > > - pushl %ecx > > > > + pushl PCB_SAVEFPU(%ecx) > > > > call npxsave > > > > - popl %ecx > > > > + addl $4,%esp > > > > popl %edx /* recover our pcb */ > > > > 1: > > > > popfl > > > > > > vm86_bioscall() in fact inlines the old version of npxexit(). > > > Shouldn't the npxexit() be called from C code before call to > > > vm86_bioscall ? > > > > I think we can but I don't like redundant or nested uses of > > critical_enter()/critical_exit() from > > vm86_intcall()/vm86_datacall(). > > Well, direct use of cli is worse, IMO. > > > And I don't think that's worth the code churn. > > 'Code churn' would remove hand-translated assembly code by calling > equivalent C version. But due to issue below, I think this fragment > should be removed at all. I just fixed it from "completely broken" to "working" state. Please feel free to commit what's best for us. You are the author of r208833 anyway. Shrug... > > > Also, if bioscall can be used from the syscall context, I think > > > whatever npxsave()/npxexit() is used, and BIOS modifies FPU > > > state, we are corrupting usermode FPU context. > > > > > > Probably, fpu_kern_enter()/fpu_kern_leave() braces around > > > vm86_bioscall is proper solution. > > > > BIOS should never modify FPU state, AFAIK. > > I believe Peter Holm still possesses the machine with quite amuzing > habit to panic sometimes during early boot, since int 12 (?) BIOS > handler tries to execute some FPU instruction and kernel has to > panic since device not present fault handler is not yet > established. Then, it won't hit vm86_bioscall() in the first place, will it? :-P > Simply put, we cannot trust BIOS. Amen! Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201101191619.08220.jkim>