Re: Seeking OK to commit KSE MIII-again
Jake Burkholder wrote: The system call stubs in libc are leaf functions; basically just a trap instruction followed by a return. They do not touch the stack at all, or change the stack pointer. One of the first few instructions on entry to the kernel is a save, which rotates the register window and logically saves the call-safe registers onto the user stack (the outs become the ins, and the kernel gets new ins and locals, with the old ones being saved to the user stack once a flush is performed or they get spilled out). Here is a reference: http://www.sparc.com/standards/v9.ps.Z Cool. Thanks for the reference. Though I think it's largely equivalent to the system call helper for threads context and stack switching in liblwp... 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII-again
Julian Elischer wrote: interesting but not exactly brief.. :-) Does brevity really matter? You asked why. I gave a reference in the general class; Jake gave a specific reference for the upcall issues he think the code will face. I think you have enough justification for Jake's position to just accept it, and move on, leaving the hard stuff to Jake. If you really want to press a large structure size for some reason, I think the ball is in your court to prove why larger is better than smaller for x86; it's been proven that it's not, for SPARC, I think. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII-again
On Thu, 30 May 2002, Peter Wemm wrote: Julian Elischer wrote: On Thu, 30 May 2002, Jake Burkholder wrote: [..] It is much more difficult to ensure that all the register values end up the same on each return from the system call on sparc64, due to the way that register stack works. The current test program will not work at all, because setjmp, longjmp cannot be used to switch the stack in the same way. The library will not be using setjmp and longjmp in this way but instead the setcontext() call that dan wrote for the current thread library. If that works it should be enough. (I'd like to investigate your comments though... can you explain more about why it's a problem? It sure simplifies things on most architectures I've done this on.. setjmp/longjmp cannot be used to switch stacks on ia64 either, for what it's worth. This is why libc_r is disabled for ia64 (and I presume sparc64). I don't really care if setjmp doesn't work, as long as there is some assembler that can be put in the library that can switch a stack/thread. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII-again
Peter Wemm [EMAIL PROTECTED] writes: If you want final commit approval/objections, you really need to either include or go to developers@ instead since they're the ones dealing with actual commit process. s/developers/arch/ DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII-again
Dag-Erling Smorgrav wrote: Peter Wemm [EMAIL PROTECTED] writes: If you want final commit approval/objections, you really need to either include or go to developers@ instead since they're the ones dealing with actual commit process. s/developers/arch/ I wasn't clear with this comment. As I said elsewhere when somebody else asked: == If he's looking for comments on the changes or reviews, he should go to arch@ as that isn't really current@ material. If he's looking for volunteers to pre-test it, then he should be asking for testers on current@. But he said he was asking for permission to commit it (Seeking OK to commit KSE MIII-again), so he should be talking with other committers. current@ is not particularly well tracked by committers themselves due to relatively low signal to noise. At the very least, you have to tell committers@ that you've posted about it elsewhere if you want it to be seen. == Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII-again
Peter Wemm [EMAIL PROTECTED] writes: But he said he was asking for permission to commit it (Seeking OK to commit KSE MIII-again), so he should be talking with other committers. I guess I just don't see why he needs our permission, as long as he's given us a chance to comment on the technical aspects of the patch. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII-again
On Thu, May 30, 2002 at 09:14:33PM +0200, Bernd Walter wrote:
On Thu, May 30, 2002 at 09:20:57AM -0700, Julian Elischer wrote:
ok, but does anyone other than john (who has commented) have any comments
about the logic and work in the change?
I'm working on his comments but comments by others would sure be
appreciated..
especially if they actually comment on what I'm trying to do..
If I can get the changes for the other architectures done,
I'd like to commit this weekend. HOPEFULLY it shouldn't
affect normal operations but of course the testing done by two people
can't hope to equal that which will be done in teh first 24 hours
once it's committed :-)
once again:
the diffs are at:
http://people.freebsd.org/~peter/kse.diff
and
http://people.freebsd.org/~julian/thediff
and the diffs I need for other architectures are versions of:
sys/i386/i386/genassym.c (small)
sys/i386/i386/machdep.c (1 line)
sys/i386/i386/swtch.s (a few lines)
sys/i386/i386/trap.c (small)
sys/i386/i386/vm_machdep.c (largly new functions, we could stub them)
sys/i386/include/kse.h (new file)
sys/i386/linux/linux_machdep.c (one line)
Largely these need to be written by someone who is intimately aquainted
with the register set of the machine in question and knows
what registers need to be saved to restore a user context correctly.
I can do the alpha part tomorrow unless someone else already startet.
There are problems with the patchset:
../../../kern/kern_proc.c: In function `fill_kinfo_proc':
../../../kern/kern_proc.c:731: `TDS_RUN' undeclared (first use in this function)
../../../kern/kern_proc.c:731: (Each undeclared identifier is reported only once
../../../kern/kern_proc.c:731: for each function it appears in.)
../../../kern/kern_proc.c:733: `SRUN' undeclared (first use in this function)
../../../kern/kern_proc.c:734: `TDS_SLEEP' undeclared (first use in this function)
../../../kern/kern_proc.c:735: `SSLEEP' undeclared (first use in this function)
../../../kern/kern_proc.c:737: `SSTOP' undeclared (first use in this function)
../../../kern/kern_proc.c:739: `SMTX' undeclared (first use in this function)
../../../kern/kern_proc.c:741: `SWAIT' undeclared (first use in this function)
../../../kern/kern_proc.c:743: syntax error before '{' token
../../../kern/kern_proc.c:744: `SZOMB' undeclared (first use in this function)
../../../kern/kern_proc.c:745: syntax error before else
../../../kern/kern_proc.c:663: warning: unused variable `tp'
../../../kern/kern_proc.c:664: warning: unused variable `sp'
../../../kern/kern_proc.c:665: warning: unused variable `tv'
[...]
Line 731 should be TDS_RUNQ I guess.
TDS_SLEEP - where is it defined - intended to be TDS_SLP?
SRUN, SSLEEP and others:
+#ifndef _KERNEL /* Only usable by libkvm for legacy apps */
+#define SIDL 1 /* Process being created by fork. */
+#define SRUN 2 /* Currently runnable. */
+#define SSLEEP 3 /* Sleeping on an address. */
+#define SSTOP 4 /* Process debugging or suspension. */
+#define SZOMB 5 /* Awaiting collection by parent. */
+#define SWAIT 6 /* Waiting for interrupt. */
+#define SMTX 7 /* Blocked on a mutex. */
+#endif
Why are they (newly) used in kern_proc.c?
IMO they need to be changed to TDS_SLP, ...
--
B.Walter COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII-again
On Fri, 31 May 2002, Bernd Walter wrote: On Thu, May 30, 2002 at 09:14:33PM +0200, Bernd Walter wrote: There are problems with the patchset: fixed This is code that translates the new states to old states for single threaded processes so that 'ps' and friends can continue to report a sensible result. (I don't want to change 'ps' yet because people will probably want to skip back and forth between new and old kernels while testing) Also it needs a complete rewrite to show multiple threads when they exist. I'd rather 'patch' the current code to work and do the rewrite as a separate item. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII-again
Apparently, On Thu, May 30, 2002 at 06:56:30PM -0700,
Julian Elischer said words to the effect of;
+ /* Note: use of M_WAITOK means it won't fail. */
+ newkse-ke_pcb =
+ (((struct md_store *)(newkse-ke_mdstorage))-mds_pcb);
+ newkse-ke_frame =
+ (((struct md_store *)(newkse-ke_mdstorage))-mds_frame);
+
+ /* Copy the upcall pcb. Kernel mode fp regs are here. */
+ bcopy(td-td_pcb, newkse-ke_pcb, sizeof(struct pcb));
+
+ /* This copies most of the user mode register values. */
+ bcopy(td-td_frame, newkse-ke_frame, sizeof(struct trapframe));
+}
ke_frame, ke_pcb and ke_mdstorage should all be in a machine dependent
struct mdkse, like mdproc. The fact that the storage is large enough
to warrant using malloc is machine dependent, so it should not be a
pointer. I would be inclined to just embed a trapframe.
e... ke_mdstorage is just a pointer to the mdstorage
as are the others.. I don't want to include an md structure into
the KSE.. it's big enough as it is.. Every process has a KSE
but only KSE-mode processes have the extra mdstorage area.
Do you feel strongly about this?
I do. The point is that if its a struct you can do what ever you want;
just put the pointers in it.
struct mdkse {
void *md_store;
struct trapframe *md_frame;
struct pcb *md_pcb;
};
I think that the upcall state should not need to be more than 3 or 4
pointers saved in the kernel, with no extra malloced stuff.
The pcb should not be needed at all here; all of the meaningful kernel
mode register values are set below. Capturing the whole execution
context at the time of the kse_new call (floating point registers,
debug registers) may be expensive and I don't think is worth doing.
Yes I started out with the PCB there but as I went I found I was needing
less and less of it. I even have a comment to that effect somewhere..
At this stage I still have it only because I wanted to make sure that
I had good defaults for anything that I wasn't sure about..
Well, the defaults are documented in the hardware documentation for
a given platform... Saving the whole pcb is not always practical,
it may be huge.
Also I haven't figured out what to do about FP registers
and I may want to stuff them there at some stage...
(not sure yet)
The whole trick of a system call that returns multiple times is
dubious. The fact that it works at all is machine dependent; for
sparc64 it needs wierd hacks in the kernel like is done for vfork.
It would be better to just register an upcall stack and entry point
with the kernel, like how signals work. This would make mdkse even
smaller.
It's effectively the same thing..
except it allows the function to have persistent state in all it's
local variables and arguments. Which is REALLY useful in the UTS.
As for hacks.. we have the code in vfork, no?
:-)
(actually the code actually uses fork_return() to do the returns so if
your hack is in there we get it for free.)
The hack is in cpu_fork. The problem is that in order to save the call
safe registers, on entry to the kernel the kernel pushes a frame onto the
_user_ stack. This saves the call safe registers that are active at the
time of the call to the kse_new asm stub in libc. When the system call
returns the frame is popped off again and the registers are restored
(again by the kernel, not the user code). However, the stack space used
to save the frame is now below the stack pointer, and will be clobbered by
interrupts, page faults, or function calls. So the next time the kse_new
call returns, the frame that was saved on the original call has been
overwritten by normal stack usage, and the call safe registers at the
time of the orignal call have been clobbered (the memory that they were
saved in that is).
Some background: obviously the kernel has to be really careful when storing
to the user stack on entry to the kernel. If that part of the stack is not
mapped, or if the stack pointer is corrupted, it can trigger a page fault or
an alignment fault. These are detected very early (before calling C code,
because we haven't even switched to the kernel stack yet), and the register
window is written to the pcb, which will be copied out again on return from
the kernel so everything looks normal.
What we do for vfork is copy the frame from the user stack into the parent's
pcb, and arrange for it to be copied out when the child exits, restoring the
volatile part of the stack. This means that we need a pcb to save the frame
in, as well as the trapframe. The pcb is huge on sparc64, as much as 5K to
6K, depending on the number of windows supported by the cpu. So we'd have
to copy almost a full page of memory for every upcall, whereas if they use
a signal style trampoline, all you need is a stack and pc, and some arguments.
+ union kse_td_ctx {
+ struct {
+ int
Re: Seeking OK to commit KSE MIII-again
Dag-Erling Smorgrav wrote: Peter Wemm [EMAIL PROTECTED] writes: But he said he was asking for permission to commit it (Seeking OK to commit KSE MIII-again), so he should be talking with other committers. I guess I just don't see why he needs our permission, as long as he's given us a chance to comment on the technical aspects of the patch. I didn't say that he does need permission. But he was asking for it. See the subject: Seeking OK to commit KSE MIII-again Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII-again
On Fri, 31 May 2002, Jake Burkholder wrote: [aweful stuff] (always did dislike sparc) jake.. can you show me the sequecne of operations performed on the stack in a syscall before and after the jump to kernel space? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII-again
Apparently, On Fri, May 31, 2002 at 01:45:50PM -0700, Julian Elischer said words to the effect of; On Fri, 31 May 2002, Jake Burkholder wrote: [aweful stuff] (always did dislike sparc) Whatever. It's the most fun architecture I've found to program for. jake.. can you show me the sequecne of operations performed on the stack in a syscall before and after the jump to kernel space? The system call stubs in libc are leaf functions; basically just a trap instruction followed by a return. They do not touch the stack at all, or change the stack pointer. One of the first few instructions on entry to the kernel is a save, which rotates the register window and logically saves the call-safe registers onto the user stack (the outs become the ins, and the kernel gets new ins and locals, with the old ones being saved to the user stack once a flush is performed or they get spilled out). Here is a reference: http://www.sparc.com/standards/v9.ps.Z Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII-again
interesting but not exactly brief.. :-) On Fri, 31 May 2002, Jake Burkholder wrote: The system call stubs in libc are leaf functions; basically just a trap instruction followed by a return. They do not touch the stack at all, or change the stack pointer. One of the first few instructions on entry to the kernel is a save, which rotates the register window and logically saves the call-safe registers onto the user stack (the outs become the ins, and the kernel gets new ins and locals, with the old ones being saved to the user stack once a flush is performed or they get spilled out). the question is when does it switch to the kernel stack? (and back?) Here is a reference: http://www.sparc.com/standards/v9.ps.Z downloaded... 300+ pages.. hmm. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII-again
Apparently, On Fri, May 31, 2002 at 05:49:59PM -0700, Julian Elischer said words to the effect of; interesting but not exactly brief.. :-) On Fri, 31 May 2002, Jake Burkholder wrote: The system call stubs in libc are leaf functions; basically just a trap instruction followed by a return. They do not touch the stack at all, or change the stack pointer. One of the first few instructions on entry to the kernel is a save, which rotates the register window and logically saves the call-safe registers onto the user stack (the outs become the ins, and the kernel gets new ins and locals, with the old ones being saved to the user stack once a flush is performed or they get spilled out). the question is when does it switch to the kernel stack? (and back?) This is not done by the hardware. Its done by the trap code after the save is executed. Here is a reference: http://www.sparc.com/standards/v9.ps.Z downloaded... 300+ pages.. hmm. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII-again
On Fri, 31 May 2002, Jake Burkholder wrote: Apparently, On Fri, May 31, 2002 at 05:49:59PM -0700, Julian Elischer said words to the effect of; interesting but not exactly brief.. :-) On Fri, 31 May 2002, Jake Burkholder wrote: The system call stubs in libc are leaf functions; basically just a trap instruction followed by a return. They do not touch the stack at all, or change the stack pointer. One of the first few instructions on entry to the kernel is a save, which rotates the register window and logically saves the call-safe registers onto the user stack (the outs become the ins, and the kernel gets new ins and locals, with the old ones being saved to the user stack once a flush is performed or they get spilled out). the question is when does it switch to the kernel stack? (and back?) This is not done by the hardware. Its done by the trap code after the save is executed. so if the software did it in the opposite order, you'd save to the kernel stack? (I doubt it but I have to ask..) Here is a reference: http://www.sparc.com/standards/v9.ps.Z downloaded... 300+ pages.. hmm. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Seeking OK to commit KSE MIII-again
ok, but does anyone other than john (who has commented) have any comments about the logic and work in the change? I'm working on his comments but comments by others would sure be appreciated.. especially if they actually comment on what I'm trying to do.. If I can get the changes for the other architectures done, I'd like to commit this weekend. HOPEFULLY it shouldn't affect normal operations but of course the testing done by two people can't hope to equal that which will be done in teh first 24 hours once it's committed :-) once again: the diffs are at: http://people.freebsd.org/~peter/kse.diff and http://people.freebsd.org/~julian/thediff and the diffs I need for other architectures are versions of: sys/i386/i386/genassym.c (small) sys/i386/i386/machdep.c (1 line) sys/i386/i386/swtch.s (a few lines) sys/i386/i386/trap.c (small) sys/i386/i386/vm_machdep.c (largly new functions, we could stub them) sys/i386/include/kse.h (new file) sys/i386/linux/linux_machdep.c (one line) Largely these need to be written by someone who is intimately aquainted with the register set of the machine in question and knows what registers need to be saved to restore a user context correctly. julian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII-again
On Thu, May 30, 2002 at 09:20:57AM -0700, Julian Elischer wrote: ok, but does anyone other than john (who has commented) have any comments about the logic and work in the change? I'm working on his comments but comments by others would sure be appreciated.. especially if they actually comment on what I'm trying to do.. If I can get the changes for the other architectures done, I'd like to commit this weekend. HOPEFULLY it shouldn't affect normal operations but of course the testing done by two people can't hope to equal that which will be done in teh first 24 hours once it's committed :-) once again: the diffs are at: http://people.freebsd.org/~peter/kse.diff and http://people.freebsd.org/~julian/thediff and the diffs I need for other architectures are versions of: sys/i386/i386/genassym.c (small) sys/i386/i386/machdep.c (1 line) sys/i386/i386/swtch.s (a few lines) sys/i386/i386/trap.c (small) sys/i386/i386/vm_machdep.c (largly new functions, we could stub them) sys/i386/include/kse.h (new file) sys/i386/linux/linux_machdep.c (one line) Largely these need to be written by someone who is intimately aquainted with the register set of the machine in question and knows what registers need to be saved to restore a user context correctly. I can do the alpha part tomorrow unless someone else already startet. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII-again
On Thu, 30 May 2002, Bernd Walter wrote: Largely these need to be written by someone who is intimately aquainted with the register set of the machine in question and knows what registers need to be saved to restore a user context correctly. I can do the alpha part tomorrow unless someone else already startet. THANKS! It shouldn't be too hard.. Julian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII-again
Julian Elischer wrote: ok, but does anyone other than john (who has commented) have any comments about the logic and work in the change? If you want final commit approval/objections, you really need to either include or go to developers@ instead since they're the ones dealing with actual commit process. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII-again
apparently, On Thu, May 30, 2002 at 09:20:57AM -0700,
Julian Elischer said words to the effect of;
ok, but does anyone other than john (who has commented) have any comments
about the logic and work in the change?
I'm working on his comments but comments by others would sure be
appreciated..
especially if they actually comment on what I'm trying to do..
If I can get the changes for the other architectures done,
I'd like to commit this weekend. HOPEFULLY it shouldn't
affect normal operations but of course the testing done by two people
can't hope to equal that which will be done in teh first 24 hours
once it's committed :-)
once again:
the diffs are at:
http://people.freebsd.org/~peter/kse.diff
and
http://people.freebsd.org/~julian/thediff
and the diffs I need for other architectures are versions of:
sys/i386/i386/genassym.c (small)
sys/i386/i386/machdep.c (1 line)
sys/i386/i386/swtch.s (a few lines)
sys/i386/i386/trap.c (small)
sys/i386/i386/vm_machdep.c (largly new functions, we could stub them)
sys/i386/include/kse.h (new file)
sys/i386/linux/linux_machdep.c (one line)
Largely these need to be written by someone who is intimately aquainted
with the register set of the machine in question and knows
what registers need to be saved to restore a user context correctly.
Index: bin/ksetest/Makefile
===
Index: bin/ksetest/kse_asm.S
===
Index: bin/ksetest/kse_threads_test.c
===
I don't know if you intended to commit this test program as well.
Please do not.
Index: sys/i386/i386/trap.c
===
@@ -942,6 +948,23 @@
td-td_frame = frame;
if (td-td_ucred != p-p_ucred)
cred_update_thread(td);
+ if (p-p_flag P_KSES) {
+ /*
+ * If we are doing a syscall in a KSE environment,
+ * note where our mailbox is. There is always the
+ * possibility that we could do this lazily (in sleep()),
+ * but for now do it every time.
+ */
+ error = copyin((caddr_t)td-td_kse-ke_mailbox +
+ offsetof(struct kse_mailbox, current_thread),
+ td-td_mailbox, sizeof(void *));
+ if (error || td-td_mailbox == NULL) {
+ td-td_mailbox = NULL; /* single thread it.. */
+ td-td_flags = ~TDF_UNBOUND;
+ } else {
+ td-td_flags |= TDF_UNBOUND;
+ }
+ }
params = (caddr_t)frame.tf_esp + sizeof(int);
The places where you access user space to setup the linkage for the
UTS should use fuword and suword instead of copyin and copyout, its
faster and it makes the code clearer.
Index: sys/i386/i386/vm_machdep.c
===
--- sys/i386/i386/vm_machdep.c2002/05/29 07:21:58 #21
+++ sys/i386/i386/vm_machdep.c2002/05/29 07:21:58
@@ -283,6 +293,145 @@
}
void
+cpu_thread_setup(struct thread *td)
+{
+
+ td-td_pcb =
+ (struct pcb *)(td-td_kstack + KSTACK_PAGES * PAGE_SIZE) - 1;
+ td-td_frame = (struct trapframe *)((caddr_t)td-td_pcb - 16) - 1;
+}
+
+struct md_store {
+ struct pcb mds_pcb;
+ struct trapframe mds_frame;
+};
+
+void
+cpu_save_upcall(struct thread *td, struct kse *newkse)
+{
+
+ /* Point the pcb to the top of the stack. */
+ newkse-ke_mdstorage = malloc(sizeof(struct md_store), M_TEMP,
+ M_WAITOK);
+ /* Note: use of M_WAITOK means it won't fail. */
+ newkse-ke_pcb =
+ (((struct md_store *)(newkse-ke_mdstorage))-mds_pcb);
+ newkse-ke_frame =
+ (((struct md_store *)(newkse-ke_mdstorage))-mds_frame);
+
+ /* Copy the upcall pcb. Kernel mode fp regs are here. */
+ bcopy(td-td_pcb, newkse-ke_pcb, sizeof(struct pcb));
+
+ /* This copies most of the user mode register values. */
+ bcopy(td-td_frame, newkse-ke_frame, sizeof(struct trapframe));
+}
ke_frame, ke_pcb and ke_mdstorage should all be in a machine dependent
struct mdkse, like mdproc. The fact that the storage is large enough
to warrant using malloc is machine dependent, so it should not be a
pointer. I would be inclined to just embed a trapframe.
The pcb should not be needed at all here; all of the meaningful kernel
mode register values are set below. Capturing the whole execution
context at the time of the kse_new call (floating point registers,
debug registers) may be expensive and I don't think is worth doing.
The whole trick of a system call that returns multiple times is
dubious. The fact that it works at all is machine dependent; for
sparc64 it needs wierd hacks in the
Re: Seeking OK to commit KSE MIII-again
On Thu, 30 May 2002, Jake Burkholder wrote:
apparently, On Thu, May 30, 2002 at 09:20:57AM -0700,
Julian Elischer said words to the effect of;
Index: bin/ksetest/Makefile
===
Index: bin/ksetest/kse_asm.S
===
Index: bin/ksetest/kse_threads_test.c
===
I don't know if you intended to commit this test program as well.
Please do not.
not planing to commit it, (except maybe under 'tools')
Index: sys/i386/i386/trap.c
===
@@ -942,6 +948,23 @@
td-td_frame = frame;
if (td-td_ucred != p-p_ucred)
cred_update_thread(td);
+ if (p-p_flag P_KSES) {
+ /*
+* If we are doing a syscall in a KSE environment,
+* note where our mailbox is. There is always the
+* possibility that we could do this lazily (in sleep()),
+* but for now do it every time.
+*/
+ error = copyin((caddr_t)td-td_kse-ke_mailbox +
+ offsetof(struct kse_mailbox, current_thread),
+ td-td_mailbox, sizeof(void *));
+ if (error || td-td_mailbox == NULL) {
+ td-td_mailbox = NULL; /* single thread it.. */
+ td-td_flags = ~TDF_UNBOUND;
+ } else {
+ td-td_flags |= TDF_UNBOUND;
+ }
+ }
params = (caddr_t)frame.tf_esp + sizeof(int);
The places where you access user space to setup the linkage for the
UTS should use fuword and suword instead of copyin and copyout, its
faster and it makes the code clearer.
Great! I've seen them mentionned several times and thought
I should see what they are but never done so..
exactly what I want!
Index: sys/i386/i386/vm_machdep.c
===
--- sys/i386/i386/vm_machdep.c 2002/05/29 07:21:58 #21
+++ sys/i386/i386/vm_machdep.c 2002/05/29 07:21:58
@@ -283,6 +293,145 @@
}
void
+cpu_thread_setup(struct thread *td)
+{
+
+ td-td_pcb =
+(struct pcb *)(td-td_kstack + KSTACK_PAGES * PAGE_SIZE) - 1;
+ td-td_frame = (struct trapframe *)((caddr_t)td-td_pcb - 16) - 1;
+}
+
+struct md_store {
+ struct pcb mds_pcb;
+ struct trapframe mds_frame;
+};
+
+void
+cpu_save_upcall(struct thread *td, struct kse *newkse)
+{
+
+ /* Point the pcb to the top of the stack. */
+ newkse-ke_mdstorage = malloc(sizeof(struct md_store), M_TEMP,
+ M_WAITOK);
+ /* Note: use of M_WAITOK means it won't fail. */
+ newkse-ke_pcb =
+ (((struct md_store *)(newkse-ke_mdstorage))-mds_pcb);
+ newkse-ke_frame =
+ (((struct md_store *)(newkse-ke_mdstorage))-mds_frame);
+
+ /* Copy the upcall pcb. Kernel mode fp regs are here. */
+ bcopy(td-td_pcb, newkse-ke_pcb, sizeof(struct pcb));
+
+ /* This copies most of the user mode register values. */
+ bcopy(td-td_frame, newkse-ke_frame, sizeof(struct trapframe));
+}
ke_frame, ke_pcb and ke_mdstorage should all be in a machine dependent
struct mdkse, like mdproc. The fact that the storage is large enough
to warrant using malloc is machine dependent, so it should not be a
pointer. I would be inclined to just embed a trapframe.
e... ke_mdstorage is just a pointer to the mdstorage
as are the others.. I don't want to include an md structure into
the KSE.. it's big enough as it is.. Every process has a KSE
but only KSE-mode processes have the extra mdstorage area.
Do you feel strongly about this?
The pcb should not be needed at all here; all of the meaningful kernel
mode register values are set below. Capturing the whole execution
context at the time of the kse_new call (floating point registers,
debug registers) may be expensive and I don't think is worth doing.
Yes I started out with the PCB there but as I went I found I was needing
less and less of it. I even have a comment to that effect somewhere..
At this stage I still have it only because I wanted to make sure that
I had good defaults for anything that I wasn't sure about..
Also I haven't figured out what to do about FP registers
and I may want to stuff them there at some stage...
(not sure yet)
The whole trick of a system call that returns multiple times is
dubious. The fact that it works at all is machine dependent; for
sparc64 it needs wierd hacks in the kernel like is done for vfork.
It would be better to just register an upcall stack and entry point
with the kernel, like how signals work. This would make mdkse even
smaller.
It's effectively the same thing..
except it allows the function to have persistent state in all it's
local
Re: Seeking OK to commit KSE MIII-again
Julian Elischer wrote: On Thu, 30 May 2002, Jake Burkholder wrote: [..] It is much more difficult to ensure that all the register values end up the same on each return from the system call on sparc64, due to the way that register stack works. The current test program will not work at all, because setjmp, longjmp cannot be used to switch the stack in the same way. The library will not be using setjmp and longjmp in this way but instead the setcontext() call that dan wrote for the current thread library. If that works it should be enough. (I'd like to investigate your comments though... can you explain more about why it's a problem? It sure simplifies things on most architectures I've done this on.. setjmp/longjmp cannot be used to switch stacks on ia64 either, for what it's worth. This is why libc_r is disabled for ia64 (and I presume sparc64). Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
