cvs commit: src/sys/compat/ndis hal_var.h kern_ndis.c subr_ndis.c subr_ntoskrnl.c subr_usbd.c winx32_wrap.S src/s

Jeff Roberson jroberson at chesapeake.net
Mon Apr 11 17:56:00 PDT 2005


On Mon, 11 Apr 2005, John Baldwin wrote:

> On Monday 11 April 2005 02:54 pm, Julian Elischer wrote:
> > Bill Paul wrote:
> > >wpaul       2005-04-11 02:02:35 UTC
> > >
> > >
> > >  The twist has to do with the fact that Microsoft supports structured
> > >  exception handling in kernel mode. On the i386 arch, exception handling
> > >  is implemented by hanging an exception registration list off the
> > >  Thread Environment Block (TEB), and the TEB is accessed via the %fs
> > >  register. The problem is, we use %fs as a pointer to the pcpu stucture,
> > >  which means any driver that tries to write through %fs:0 will overwrite
> > >  the curthread pointer and make a serious mess of things.
> > >
> > >  To get around this, Project Evil now creates a special entry in
> > >  the GDT on each processor. When we call into Windows code, a context
> > >  switch routine will fix up %fs so it points to our new descriptor,
> > >  which in turn points to a fake TEB. When the Windows code returns,
> > >  or calls out to an external routine, we swap %fs back again. Currently,
> > >  Project Evil makes use of GDT slot 7, which is all 0s by default.
> > >  I fully expect someone to jump up and say I can't do that, but I
> > >  couldn't find any code that makes use of this entry anywhere. Sadly,
> > >  this was the only method I could come up with that worked on both
> > >  UP and SMP. (Modifying the LDT works on UP, but becomes incredibly
> > >  complicated on SMP.) If necessary, the context switching stuff can
> > >  be yanked out while preserving the convention calling wrappers.
> >
> > Maybe we could emulate $soft and use %fs as a thread pointer instead and
> > have pcpu
> > pointed to via that :-)
>
> I think NDIS drivers want %fs to point to a Windows-specific structure rather
> than a 'struct thread' so I don't think that would buy us anything except for
> even more memory indirects when we do a pcpu lookup.

Isn't curthread a much more frequent fetch than PCPU anything?  It might
actually be a win.

>
> --
> John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
> "Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
>


More information about the cvs-src mailing list