cvs commit: src/sys/compat/ndis hal_var.h kern_ndis.c kern_windrv.c ndis_var.h ntoskrnl_var.h pe_var.h subr_hal.c subr_ndis.c subr_ntoskrnl.c subr_usbd.c winx32_wrap.S src/s

[John Baldwin]

On Monday 11 April 2005 08:55 pm, Jeff Roberson wrote:
> 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.

Fetching curthread is already a single op:

	mv %fs:0x4, %eax

(or whatever offset it is).  Unless you wanted to map all thread members of 
curthread which would result in lots of ugly code (use cuthread_get(foo) 
instead of curthread->td_foo to use it) plus problems with getting an actual 
real KVA for curthread you wouldn't get any better.

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