Date: Tue, 18 Sep 2001 22:35:06 -0700 From: Julian Elischer <julian@elischer.org> To: Peter Wemm <peter@wemm.org> Cc: John Baldwin <jhb@FreeBSD.ORG>, hackers@FreeBSD.ORG Subject: Re: JKH Project: x86: pcb_ext Message-ID: <3BA82E8A.E297428E@elischer.org> References: <20010919042928.F229F380A@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm wrote:
>
> John Baldwin wrote:
> > Here's a Junior Kernel Hacker project for someone:
> >
> > - Move pcb_ext and pcb_ldt out of the pcb of struct thread and into
> > struct mdproc; I.e., you probably want to do something like this:
> > - Rename struct pcb_ext to struct proc_tss and struct pcb_ldt to
> > struct proc_ldt. (Fixup pcb_ext member names to use a tss_
> > prefix instead of ext_)
> > - Have a struct mdproc as so:
> >
> > struct mdproc {
> > struct proc_tss *md_tss;
> > struct proc_ldt *md_ldt;
> > }
> >
> > Prior to KSE this was just annoyance but wasn't an actual problem. With KSE
> > threads are temporary, whereas the ldt and tss are per-process properties
> > that need to stick around.
>
> Just so that somebody doesn't get a nasty suprise.. this is not as
> simple as it sounds.. There are several configurations of "extended" pcb,
> including having a seperate i386tss.. The nasty part is that some of this
> is per-thread because there is a per-thread kernel stack pointer embedded
> in it.
per cpu and per process... this is the domain of the KSE..
It should be duplicated from the 'master' one for each KSE created,
and the appropriate stack pointer shifted into it
when the thread is attached to the KSE to run.
Since KSEs are per processor, there can only be one processor using
each at a time, however there is still a problem with keeping the extensions
UP TO DATE with each others when they are changed... We should be ok, if
changes to the extension are only done via a well defined interface though.
>
> The upshot of this is that there probably needs to be a "master" pcb extension
> that gets propagated to thread children.
>
> In particular, look at these fragmets of swtch.s:
>
> movl PCB_EXT(%edx), %edi /* new tss descriptor */
> [..]
> movl %edx, PCPU(COMMON_TSS) + TSS_ESP0 /* stack is below pcb */
> [..]
> movl PCPU(TSS_GDT), %ebx /* entry in GDT */
> movl 0(%edi), %eax
> movl %eax, 0(%ebx)
> movl 4(%edi), %eax
> movl %eax, 4(%ebx)
> movl $GPROC0_SEL*8, %esi /* GSEL(entry, SEL_KPL) */
> ltr %si
>
> I think this is actually broken right now since the tss_esp0 is pointing
> to the wrong location.. It's actually pointing to an unmapped page.
>
> And note how we install the per-thread tss extension pointer into the
> per-cpu tss slot in the gdt.
>
> And, sys_machdep.c:
> ext->ext_tss.tss_esp0 = td->td_kstack + ctob(KSTACK_PAGES) -
> sizeof(struct pcb) - 16;
>
> We cannot entirely move the extended tss into into a mdproc since td_kstack
> is different in each thread.
>
> The more I think about it, the right place may be the kse, since that outlives
> the threads and is per-cpu unlike the process.
ah yes.. that's what I said......
>
> Or, we just say "no pcb extensions for kse processes".
I think we can do it.. though what would it be useful for?
(unlikely that Multiple threads would be that useful in emulating
DOS programs.. NT programs, maybe but the addaption layer would be a
nightmare..)
>
> Cheers,
> -Peter
> --
> Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
> "All of this is for nothing if we don't go to the stars" - JMS/B5
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
--
+------------------------------------+ ______ _ __
| __--_|\ Julian Elischer | \ U \/ / hard at work in
| / \ julian@elischer.org +------>x USA \ a very strange
| ( OZ ) \___ ___ | country !
+- X_.---._/ presently in San Francisco \_/ \\
v
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BA82E8A.E297428E>