> Hi, I have more questions about the internals of gnumach (oskit-mach to
> be more precise). I have either not been able to find answers to them, or
> it's very difficult to deduce them from the sourcecode.
I don't have source handy this moment, so I am answering from memory and/or
from assumptions of what the reasonable things to be doing are. So rather
than answers per se, I can just advise you what to look for in the code.
Anyway, hopefully someone already answered these questions for you while I
was out of town last week--I haven't gotten to reading pent-up mailing list
messages yet.
> 1. Where, if anywhere, does gnumach change into virtual 8086 mode? If it does
> then what purpose does it serv? If it doesn't and and if only the kernel
> code has high enough privelege level to change to vm86 mode, why is it
> even mentioned in the code (in a few placed deep in i386/i386/)?
There is nothing that works now, or at least that we are using, that uses
virtual 8086 mode. The only purpose of vm86 mode is for things like DOS
emulators, and such were supported under Mach 3.0 in the past. I believe
there are special i386-specific RPC interfaces to invoke that stuff, but I
would be wholly unsurprised if none if it were usable in the current state
of the code.
> 2. I've noticed that the `copyin' routine (defined in i386/i386/locore.S)
> does no checking as to whether it's accessing valid memory from user space.
> Where is the user space address checked for validity before invoking `copyin'?
The way this usually works is that the kernel PC addresses within
copyin/copyout are known specially by the trap handler so that the
kernel-mode trap from a bad access gets warped into the copyin/copyout
function returning an error to its caller. IIRC, a special segment
register value is used to access user addresses (USER_DS); the segmentation
setup for that segment selector ensures that only user addresses can be seen.
> 3. And what *does* happen if there is a page fault from kernel space while
> accessing user space memory? `kernel_trap()' in i386/i386/trap.c seems
> rather pessimistic and panics a lot. If the user supplied an invalid address
> would it not be appropriate to raise an access violation exception?
That is certainly what happens. I don't recall off hand exactly which code
detects the case. kernel_trap is not the trap handler itself, but a
function called from the assembly code.
