how does the processor know an instruction is making a system call

Question

system call -- It is an instruction that generates an interrupt that causes OS to gain control of processor.

so if a running process issue a system call (e.g. create/terminate/read/write etc), a interrupt is generated which cause the KERNEL TO TAKE CONTROL of the processor which then executes the required interrupt handler routine. correct?

then can anyone tell me how the processor known that this instruction is supposed to block the process, go to privileged mode, and bring kernel code.

I mean as a programmer i would just type stream1=system.io.readfile(ABC) or something, which translates to open and read file ABC.

Now what is monitoring the execution of this process, is there a magical power in the cpu to detect this?

As from what i have read a PROCESSOR can only execute only process at a time, so WHERE IS THE MONITOR PROGRAM RUNNING?

How can the KERNEL monitor if a system call is made or not when IT IS NOT IN RUNNING STATE!!

or does the computer have a SYSTEM CALL INSTRUCTION TABLE which it compares with before executing any instruction?

please help

thanku

Answer 1

The kernel doesn't monitor the process to detect a system call. Instead, the process generates an interrupt which transfers control to the kernel, because that's what software-generated interrupts do according to the instruction set reference manual.

For example, on Unix the process stuffs the syscall number in eax and runs an an int 0x80 instruction, which generates interrupt 0x80. The CPU reacts to this by looking in the Interrupt Descriptor Table to find the kernel's handler for that interrupt. This handler is the entry point for system calls.

So, to call _exit(0) (the raw system call, not the glibc exit() function which flushes buffers) in 32-bit x86 Linux:

movl  $1, %eax   # The system-call number.  __NR_exit is 1 for 32-bit
xor   %ebx,%ebx  # put the arg (exit status) in ebx
int   $0x80

Answer 2

Let's analyse each questions you have posed.

1. Yes, your understanding is correct.

2. See, if any process/thread wants to get inside kernel there are only two mechanisms, one is by executing TRAP machine instruction and other is through interrupts. Usually interrupts are generated by the hardware, so any other process/threads wants to get into kernel it goes through TRAP. So as usual when TRAP is executed by the process it issues interrupt (mostly software interrupt) to your kernel. Along with trap you will also mentions the system call number, this acts as input to your interrupt handler inside kernel. Based on system call number your kernel finds the system call function inside system call table and it starts to execute that function. Kernel will set the mode bit inside cs register as soon as it starts to handle interrupts to intimate the processor as current instruction is a privileged instruction. By this your processor will comes to know whether the current instruction is privileged or not. Once your system call function finished it's execution your kernel will execute IRET instruction. Which will clear mode bit inside CS register to inform whatever instruction from now inwards are from user mode.

3. There is no magical power inside processor, switching between user and kernel context makes us to think that processor is a magical thing. It is just a piece of hardware which has the capability to execute tons of instructions at a very high rate.

4..5..6. Answers for all these questions are answered in above cases.

I hope I've answered your questions up to some extent.

Answer 3

The interrupt controller signals the CPU that an interrupt has occurred, passes the interrupt number (since interrupts are assigned priorities to handle simultaneous interrupts) thus the interrupt number to determine wich handler to start. The CPu jumps to the interrupt handler and when the interrupt is done, the program state reloaded and resumes.

[Reference: Silberchatz, Operating System Concepts 8th Edition]

Answer 4

What you're looking for is mode bit. Basically there is a register called cs register. Normally its value is set to 3 (user mode). For privileged instructions, kernel sets its value to 0. Looking at this value, processor knows which kind of instruction it is. If you're interested digging more please refer this excellent article.

Other Ref.

Where is mode bit

Answer 5

Modern hardware supports multiple user sessions. If your hw supports multi user mode, i provides a mechanism called interrupt. An interrupt basically stops the execution of the current code to execute other code (e.g kernel code). Which code is executed is decided by parameters, that get passed to the interrupt, by the code that issues the interrupt. The hw will increase the run level, load the kernel code into the memory and forces the cpu to execute this code. When the kernel code returns, it again directly informs the hw and the run level gets decreased. The HW will then restore the cpu state before the interrupt and set the cpu the the next line in the code that started the interrupt. Done. Since the code is actively calling the hw, which again actively calls the kernel, no monitoring needs to be done by the kernel itself.

Side note: Try to keep your question short. Make clear what you want. The first answer was correct for the question you posted, you just didnt phrase it well. Make clear that you are new to the topic and need a detailed explanation of basic concepts instead of explaining what you understood so far and don't use caps lock.

Please accept the answer cnicutar provided. thank you.