system calls

[Tim]

A couple of hundred cycles. I'm not sure but I'd say that interrupts are the fastest way of changing rings without using the new system call instructions. And of course, how can you do system calls on older machines without interrupts?

[ncsu121978]

well i would think that only the process that is currently executing on the processor would be able to generate a system call interrupt....that is how I will know which process generated the interrupt.
Or am I missing something here ?

[Tom]

Yes...you can do that...I even made a test when I had my IDT working...still trying yours....

[Tim]

ncsu121978: right. The kernel is the only thing that knows how to switch processes, therefore you will always know which process is issuing system calls.

There should also be no address space switch in the kernel side of an interrupt, so any data from the calling process will be accessible from the kernel. It's a good idea to keep all the kernel code and data mapped into every address space.

[Dave_Hunt]

Good point. I haven't given this much thought lately and it shows

Question: If there is no address space switch on the kernel side, how does the kernel get access to it's own data?

Assume the kernel is loaded at physical address 0. Then pointer pKernelData = 0x1000 points to physical address 0x1000. A user process loaded at physical address 0x100000 but logical address 0x000000 passes pointer 0x1000 to the kernel.

Without an address space switch, the user pointer works fine. I read/write data at physical address 0x101000. However, when the kernel references pKernelData during this interrupt, would it not also read/write physical address 0x101000?

I know I'm missing something and this is where I set my project aside awaiting some kind of "Aha!" experience.

[Tim]

Easy: you don't put the kernel and the user code both at logical address zero.

An address space is one set of logical->physical mappings defined by the current page directory and page tables. Within one address space (i.e. for one value of CR3), address zero is address zero regardless of whether you're in user or kernel mode (unless you start using segmentation).

NT and Linux handle this by splitting each address space into user and kernel halves; NT gives 0x80000000 upwards to the kernel (unless you use the /3GB switch), Linux is at 0xC0000000 upwards. The kernel part is shared throughout all address spaces.

I think I cover this in my memory management tutorials.

[Dave_Hunt]

Aha!

I always wondered what the benefit of putting the kernel at logical 0x80000000 or 0xC0000000 was.

So let me see if I have this right:

I map the kernel to logical address 0x80000000. I map the kernel address space into each user process page directory. I can load each user process at logical address 0. I skip the address space switch at syscall time and the kernel gets access to both the calling process space and kernel space without any user->kernel pointer translations.

Why didn't I see that before? Doh.

[K.J.]

Out of curiosity, why does almost no one map their kernel @ 0x0 and user data starting @ 0x40000000(the 1gb mark)? I'm doing this(well, slight variation, kernel is started @ 0x100000) and so far have not had any problems with it. Any particlular reason everyone else tends to the opposite?

K.J.

[Tim]

Dave: Spot on.

K.J.: No real reason why that shouldn't work, except that you won't be able to use V86 mode in that configuration. V86 mode is hard-wired to access memory starting at virtual address zero.

[PlayOS]

KJ should be able to use v86 if he reserves the first 1MB of memory, as he appears to do by having the kernel at 1MB, this is right isn't it?

[Pype.Clicker]

note that even with kernel located below 1Mb, you still have the opportunity to play with paging so that the V86 don't see/overwrite kernel code ...
(though it is probably a lot more complicated that having kernel >1Mb ...)

[Tim]

Well, you'd have to make the bottom 1MB user-accessible, then have the kernel, then have user mode again. Or you could make *all* the bottom half user, and all the top half kernel.