Date: Sat, 25 Mar 2000 17:51:06 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Anyone know why the syscall interface is using the doreti mechanism? Message-ID: <Pine.BSF.4.21.0003251654510.405-100000@alphplex.bde.org> In-Reply-To: <200003241157.DAA10683@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 24 Mar 2000, Matthew Dillon wrote: > I understand why interrupts use the doreti mechanism. I don't understand > why the syscall interface traps have to use it. As far as I can tell, To handle AST's (for signals and forced context switches, etc), and to do the special stuff before iret (magic addresses for error handling, and giant lock releasing) in a uniform way. AST's must be checked for somehow, and doreti has an efficient method for doing so. I once put the AST-pending bit in `ipending' so that it could be checked in the same instruction that checks for pending interrupts. This turned out to have been not worth doing, so I went back to the old (386BSD-0.0?) way last July. I profiled inlining the `ipending' check at the end of Xsyscall() long ago when i486's were fast. Unsurprisingly, it was not worth doing (it only saved approximately one jump instruction). Branch target buffers, etc. in modern x86's probably don't make much difference. Inlining the separate `astpending' check is more likely to be right, but duplication the complications before iret at the end of several syscall routines would be ugly. > the cpl stuff does not have to be checked at all, the spl does not have > to be set to 0 (it damn well better already be 0!), pending interrupts > should not have to be checked because interrupts are operating just fine > and any code that raises the spl will have dropped it prior to returning, Correct. > So really only astpending needs to be checked... which can be done inside > syscall() rather then doreti. The duplication for this would be ugly (see above). Note that astpending still has to be checked for after an interrupt, since if the interrupt occurred in user mode then it may have generated an AST. > What am I doing? I'm experimenting with trying to remove the MP lock > from the syscall path (in exception.s and trap.c). I added a per-syscall Of course, if you need non-uniform handing before iret, then jumping to doreti to get uniform handling is wrong. > flag to tell syscall() whether any given syscall is MP safe or not, > and if the syscall IS MP safe then the entire nominal path can be run > without obtaining the MP lock. I think luoqi has already done something like this. In fact, I was motivated by his work to remove the AST-pending bit from `ipending'. He has some other changes related to AST-pending and SMP (`astpending' cannot work right for SMP since it is not per-cpu...). Development seems to have stalled. > It was all very straightforward except for the doreti stuff that > the two syscall gates in i386/i386/excep4tion.s return through. > Now, I know I MUST be missing something... but the friggin system > is working! No lockups or anything. I'm confident that if I *AM* > missing something it will be relatively easy to fix. For the doreti > stuff I, well, I ripped it out and replaced it with a few pops and an > iret. > > So question #1: Why is my system still working, what I did has *got* > to be illegal! The darned thing is doing a buildworld as I type... > still no crash. It isn't getting stuck. Nothing, nada. Normal > boring operation. Not even a cool panic! Well, returning from syscall() without jumping to doreti would break only AST's and trapping of invalid user stacks and segment registers. This loss is not important in normal operation. AST's are needed mainly to kill CPU hogs and to deliver signals promptly. Trapping invalid user stacks, etc., is needed mainly to stop the kernel panicing for invalid contexts in sigreturn(). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0003251654510.405-100000>