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

[Jung-uk Kim]

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