And like that wouldn't be enough once you start using sysenter all the
other seemingly minor details start to bite you (like it looses not only
VM but also the IF flag. so now every syscall turns on interrupts...
I guess i'll have to declare that a feature :) )
> It wouldn't be a C entry-point: it would really be an assembly
> entry-point, and you'd have special calling conventions for it (for one
> thing, you'd have to set up %eax to be the system call number).
I am not convinced doing the magic entry point will be a win; i
certainly agree with Ulrich that the libc solution is more attractive.
But we'll get the global fixmapped region anyway, so there's a chance
we will be able to compare both.
> As far as the kernel would be concerned, it would be just another of the
> "high virtual memory mappings" - the kernel already uses them internally
> simply because it is a good idea to avoid a pointer lookup for some things
> that are so common that you can more efficiently cache them in the TLB. So
> the kernel as certain magical addresses where the IO-APIC is always at one
> fixed virtual address instead of having to be looked up on every access to
> it.
>
> So this would be just another such "virtually pinned" page, except it
> would be readable from user space too (but obviously not writable). It can
> contain any number of trampolines and/or other data (although I don't
> really see what static data would ever be that timing-critical).
hmm, rdtsc based gettimeofday?
> > I did consider this. The reasons i didn't do it that way were (1) to
> > make it as nonitrusive as possible (the patch currently is just a few
> > dozen lines) and (2) policy -- adding hardwired userspace mappings.
> > (the performance difference would be ~ a few cycles, so that's not a
> > big issue). Now, if (1) isn't a problem i may consider that scheme again.
> > Assuming nobody sees any problems w/ (2) above?
>
> Note that we definitely don't want to eat up virtual space in the
> "traditional" user space area - 0x00000000 - 0xC0000000. The pinned down
> thing would be a kernel mapping, basically a vmalloc()-like thing except
> normal vmallocs are not accessible from user space (the page tables have
> been set up to not allow access to them for obvious reasons).
>
> (And no, I'm not really suggesting you use vmalloc() - I'm really
> suggesting you look at the stuff in <asm/fixmap.h> which gets set up at
> predefined addresses rather than the more dynamic vmalloc()).
i did look after the first time you mentioned it.
i'll try playing with that.
> sysenter is really a strange thing. Have you verified that your current
> code works with vm86 mode programs like dosemu or with wine, for example?
No, it does not. I haven't even written the code handling that case, for
the very simple reason i haven't yet figured out _what_ to do when a
vm86 task executes SYSENTER. This is one of only two unresolved issues
left. As it is impossible to recover from this (w/o a cooperative
userspace, that is. sysenter drops eip/esp/cs/ss) what should happen?
[i don't use any vm86 tasks so i'd find it acceptable to simply _exit(),
but there might be a better way... Ideas?]
Oh, there's something else i have on the todo list, but haven't yet
looked into -- SYSENTER doesn't clear TF.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/