svn commit: r217587 - head/sys/i386/i386

[Kostik Belousov]

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.

> 
> > 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.

Simply put, we cannot trust BIOS.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-all/attachments/20110119/64960f1f/attachment.pgp