in Operating System
30 votes

Normally user programs are prevented from handling I/O directly by I/O instructions in them. For CPUs having explicit I/O instructions, such I/O protection is ensured by having the I/O instruction privileged. In a CPU with memory mapped I/O, there is no explicit I/O instruction. Which one of the following is true for a CPU with memory mapped I/O?

  1. I/O protection is ensured by operating system routine(s)

  2. I/O protection is ensured by a hardware trap

  3. I/O protection is ensured during system configuration

  4. I/O protection is not possible

in Operating System


Please confirm this answer between options a) & b)      @Bikram sir
edited by


It is option A , is correct.

see this line 

Normally user programs are prevented from handling I/O directly by I/O instructions in them , For CPUs having explicit I/O instructions, such I/O protection is ensured by having the I/O instruction privileged.

this means explicit I/O is done at kernel mode , it can not done in user mode.

In a CPU with memory mapped I/O, there is no explicit I/O instruction so protection is ensured by operating system routines only . As in kernel mode only OS can handle the task . And Kernal mode deals with system calls. So option A is appropriate here ..

@Tuhin datta trap is a software signal raised during errors in the code not for I/O SO B IS WRONG
@Bikram So in isolated IO, IO protection is ensured by hardware trap as in option B?
edited by
@Bikram sir, I think option B is correct. Following is the explanation(please correct me if I am wrong).

In case of CPU with explicit I/O instruction, protection is provided by having I/O instruction privileged. So that if user process executes an I/O instruction then it will result in a hardware trap as it is not in kernel mode.

Now,  thinking in the same line if we consider case of memory mapped I/O. Here we have some address range which is used to access I/O device, so we can do I/O operation by simple memory access operations. Now, in order to provide I/O protection we should not allow any user process to access that region of address. This can be implemented by using two registers (limit and base), such that if any address produced by a user process lies between  limit and base then it produces a harware trap. But if it is accessed by kernel process then it should not result in a trap (as it is kernel mode).

ultimately in both cases we want to protect user process from directly doing I/O, and we want it to leave off burden of doing I/O task to os.

Subscribe to GO Classes for GATE CSE 2022

4 Answers

45 votes
Best answer

Option (A). User applications are not allowed to perform I/O in user mode - All I/O requests are handled through system calls that must be performed in kernel mode.

edited by


How is I/O protection ensured by CPU having isolated mapped I/O?
When it comes to memory mapped IO, a simple LOAD instruction can read the address range mapped to any IO device, right ? So if I am correct a non-IO instruction will be able to read from device. I agree with the above option, but the explanition does not seem correct

Registered user 31  

Explanation given is correct too ..

From question , it is clear that user can not handle I/O execution.So I/O is perform at kernel mode only ..

  • The kernel  is a trusted software to OS, but all other programs are considered un-trusted software.
  • Thus, all user mode software must request use of the kernel by means of a system call in order to perform privileged instructions, such as process creation or input/output operations. 


User cannot handle I/O protection directly. It is handles by program (or routine) of OS

Source: Galvin Chapter 13 Topic I/O Protection

[ Some softwares need direct access to memory mapped graphics controller memory. The kernel might provide a "locking mechanism to allow a section of graphics memory to be allocated to one process at a time". ] Doesn’t this imply a hardware trap ?

0 votes

Since the IO instructions are not explicit in memory mapped IO, OS can't know just by seeing the instruction that whether it's an IO instruction or memory instruction. Thus when address space belongs to IO devices it triggers a hardware trap which makes the CPU aware that this is an IO instruction.

1 comment

A trap usually results in a switch to kernel mode, wherein the operating system performs some action before returning control to the originating process.. a type of synchronous interrupt typically caused by an exceptional condition .

Trap is more like an exception... so I/O protection can not be hardware trap.

0 votes

Option A) is correct. Kernel space switching is achieved by Software Interrupt, which changes the processor mode and jump the CPU execution into interrupt handler, which executes corresponding System Call routine.

Ref: User mode and Kernel mode Switching - GeeksforGeeks

0 votes


Accessing devices

Devices, such as network or USB controllers, come with their own control logic that is usually governed by a microcontroller or some other processor that resides on the device. The control logic supports some form of programming interface to allow the host system to send requests to transmit data, receive data, see if data is ready, write data, read data, seek to a location, or get the status of a device. The actual functions, of course, depend on the device.

An clean way of interacting with peripheral devices is to map the device’s command registers onto the system memory bus. This way, accessing certain memory locations will not reference system memory but instead read and write data to the device registers. The beauty of this scheme is that the programmer can use standard memory load and store instructions. Moreover, the memory protection mechanisms provided by the processor and set up by the operating system now cover device access too. This technique of mapping device input/output to memory is called memory-mapped I/O.

Device registers also tell you when data is ready (e.g., a packet has been received) or if the device is ready for more data (e.g., a packet has been transmitted). We could have our operating system sit in a busy loop and check these registers. Unfortunately, we will chew up tons of processor cycles just waiting for the device and not be able to use the time to do anything else. Instead, whenever we get a periodic clock interrupt (e.g., every 10 milliseconds), we can have the operating system go and check those device registers. That avoids the busy loop.

An alternative, and more popular, approach to this is to have the peripheral device trigger an interrupt whenever the device has data or when the device informs the system that it has finished transmitting and can accept more data. The benefit of an interrupt is that the processor does not have to do any checking until the device pokes it. The downside is that the interrupt will force a mode switch and that may be time consuming. On some systems, it may also invoke a context switch, which is even more costly. On startup, a device driver registers an interrupt handler. Whenever the interrupt takes place, the interrupt handler is invoked and is responsible for handling that interrupt. Since interrupts are precious resources (a processor may have only 16 or so of them), a device driver may sometimes have to share an interrupt line with other device drivers. In this case, the kernel will call each driver that registered that interrupt in sequence.

Moving data between the device and the kernel can also be accomplished by reading and writing the device registers (i.e., reading and writing specific memory locations to which those registers have been mapped). This is called programmed I/O since software is responsible for moving the bytes between main memory and the device via the device’s registers. 


Related questions