AOS Lab 8: Interrupts and Device Drivers

719 views
597 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
719
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
24
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

AOS Lab 8: Interrupts and Device Drivers

  1. 1. Lab 8: Interrupts and Device Drivers Advanced Operating Systems Zubair Nabi zubair.nabi@itu.edu.pk March 28, 2013
  2. 2. Recap of Lab 5: Extraordinary events Events that break normal processor flow, to return control to the kernel: 1 A device signals that it needs attention (e.g. Timer): Interrupt 2 A user program does something illegal (e.g. divide by zero): Exception 3 A user program asks the kernel for a service: System call
  3. 3. Recap of Lab 5: Extraordinary events Events that break normal processor flow, to return control to the kernel: 1 A device signals that it needs attention (e.g. Timer): Interrupt 2 A user program does something illegal (e.g. divide by zero): Exception 3 A user program asks the kernel for a service: System call
  4. 4. Recap of Lab 5: Extraordinary events Events that break normal processor flow, to return control to the kernel: 1 A device signals that it needs attention (e.g. Timer): Interrupt 2 A user program does something illegal (e.g. divide by zero): Exception 3 A user program asks the kernel for a service: System call
  5. 5. Recap of Lab 5: Extraordinary events Events that break normal processor flow, to return control to the kernel: 1 A device signals that it needs attention (e.g. Timer): Interrupt 2 A user program does something illegal (e.g. divide by zero): Exception 3 A user program asks the kernel for a service: System call
  6. 6. Recap of Lab 5: Handling extraordinary events The operating system must: 1 Save the processor’s registers for future resumption 2 Set up system for execution in the kernel 3 Choose a place for the kernel to start execution 4 Retrieve information about the event and call corresponding interrupt handler 5 All the while, maintain isolation between user processes and the kernel
  7. 7. Recap of Lab 5: Handling extraordinary events The operating system must: 1 Save the processor’s registers for future resumption 2 Set up system for execution in the kernel 3 Choose a place for the kernel to start execution 4 Retrieve information about the event and call corresponding interrupt handler 5 All the while, maintain isolation between user processes and the kernel
  8. 8. Recap of Lab 5: Handling extraordinary events The operating system must: 1 Save the processor’s registers for future resumption 2 Set up system for execution in the kernel 3 Choose a place for the kernel to start execution 4 Retrieve information about the event and call corresponding interrupt handler 5 All the while, maintain isolation between user processes and the kernel
  9. 9. Recap of Lab 5: Handling extraordinary events The operating system must: 1 Save the processor’s registers for future resumption 2 Set up system for execution in the kernel 3 Choose a place for the kernel to start execution 4 Retrieve information about the event and call corresponding interrupt handler 5 All the while, maintain isolation between user processes and the kernel
  10. 10. Recap of Lab 5: Handling extraordinary events The operating system must: 1 Save the processor’s registers for future resumption 2 Set up system for execution in the kernel 3 Choose a place for the kernel to start execution 4 Retrieve information about the event and call corresponding interrupt handler 5 All the while, maintain isolation between user processes and the kernel
  11. 11. Recap of Lab 5: Handling extraordinary events The operating system must: 1 Save the processor’s registers for future resumption 2 Set up system for execution in the kernel 3 Choose a place for the kernel to start execution 4 Retrieve information about the event and call corresponding interrupt handler 5 All the while, maintain isolation between user processes and the kernel
  12. 12. Recap of Lab 5: Handling extraordinary events (2) • Need hardware support • On the x86, system calls generate an interrupt via the int instruction • The same mechanism for handling interrupts is used for handling system calls and exceptions • Traps are caused by the current running process • Interrupts are caused by devices • Can happen concurrently
  13. 13. Recap of Lab 5: Handling extraordinary events (2) • Need hardware support • On the x86, system calls generate an interrupt via the int instruction • The same mechanism for handling interrupts is used for handling system calls and exceptions • Traps are caused by the current running process • Interrupts are caused by devices • Can happen concurrently
  14. 14. Recap of Lab 5: Handling extraordinary events (2) • Need hardware support • On the x86, system calls generate an interrupt via the int instruction • The same mechanism for handling interrupts is used for handling system calls and exceptions • Traps are caused by the current running process • Interrupts are caused by devices • Can happen concurrently
  15. 15. Recap of Lab 5: Handling extraordinary events (2) • Need hardware support • On the x86, system calls generate an interrupt via the int instruction • The same mechanism for handling interrupts is used for handling system calls and exceptions • Traps are caused by the current running process • Interrupts are caused by devices • Can happen concurrently
  16. 16. Recap of Lab 5: Handling extraordinary events (2) • Need hardware support • On the x86, system calls generate an interrupt via the int instruction • The same mechanism for handling interrupts is used for handling system calls and exceptions • Traps are caused by the current running process • Interrupts are caused by devices • Can happen concurrently
  17. 17. Recap of Lab 5: Handling extraordinary events (2) • Need hardware support • On the x86, system calls generate an interrupt via the int instruction • The same mechanism for handling interrupts is used for handling system calls and exceptions • Traps are caused by the current running process • Interrupts are caused by devices • Can happen concurrently
  18. 18. Recap of Lab 5: trap • Gets passed struct trapframe *tf • Checks tf->trapno to decide if it was called for a system call (T_SYSCALL) or a hardware interrupt or an exception • In case of: 1 System call, it invokes syscall 2 3 Hardware interrupt, it calls the hardware interrupt controller Exception, it prints the details and kills the user process
  19. 19. Recap of Lab 5: trap • Gets passed struct trapframe *tf • Checks tf->trapno to decide if it was called for a system call (T_SYSCALL) or a hardware interrupt or an exception • In case of: 1 System call, it invokes syscall 2 3 Hardware interrupt, it calls the hardware interrupt controller Exception, it prints the details and kills the user process
  20. 20. Recap of Lab 5: trap • Gets passed struct trapframe *tf • Checks tf->trapno to decide if it was called for a system call (T_SYSCALL) or a hardware interrupt or an exception • In case of: 1 System call, it invokes syscall 2 3 Hardware interrupt, it calls the hardware interrupt controller Exception, it prints the details and kills the user process
  21. 21. Recap of Lab 5: trap • Gets passed struct trapframe *tf • Checks tf->trapno to decide if it was called for a system call (T_SYSCALL) or a hardware interrupt or an exception • In case of: 1 System call, it invokes syscall 2 3 Hardware interrupt, it calls the hardware interrupt controller Exception, it prints the details and kills the user process
  22. 22. Recap of Lab 5: trap • Gets passed struct trapframe *tf • Checks tf->trapno to decide if it was called for a system call (T_SYSCALL) or a hardware interrupt or an exception • In case of: 1 System call, it invokes syscall 2 3 Hardware interrupt, it calls the hardware interrupt controller Exception, it prints the details and kills the user process
  23. 23. Interrupts • Examples of interrupts: Pressing a key on the keyboard, storing data on disk etc. • Hardware on the motherboard signals the CPU whenever a device needs attention • Devices need to be programmed to generate interrupts • Interrupts must be assigned to a CPU for handling
  24. 24. Interrupts • Examples of interrupts: Pressing a key on the keyboard, storing data on disk etc. • Hardware on the motherboard signals the CPU whenever a device needs attention • Devices need to be programmed to generate interrupts • Interrupts must be assigned to a CPU for handling
  25. 25. Interrupts • Examples of interrupts: Pressing a key on the keyboard, storing data on disk etc. • Hardware on the motherboard signals the CPU whenever a device needs attention • Devices need to be programmed to generate interrupts • Interrupts must be assigned to a CPU for handling
  26. 26. Interrupts • Examples of interrupts: Pressing a key on the keyboard, storing data on disk etc. • Hardware on the motherboard signals the CPU whenever a device needs attention • Devices need to be programmed to generate interrupts • Interrupts must be assigned to a CPU for handling
  27. 27. Handing interrupts on multi-processors Two parts of handling interrupts on multi-processors 1 A method to route interrupts to processors (I/O APIC – Advanced Programmable Interrupt Controller, ioapic.c) 2 A per CPU interrupt controller to handle interrupts (Local APIC, lapic.c) The OS needs to program both the IOAPIC and the LAPIC
  28. 28. Handing interrupts on multi-processors Two parts of handling interrupts on multi-processors 1 A method to route interrupts to processors (I/O APIC – Advanced Programmable Interrupt Controller, ioapic.c) 2 A per CPU interrupt controller to handle interrupts (Local APIC, lapic.c) The OS needs to program both the IOAPIC and the LAPIC
  29. 29. Handing interrupts on multi-processors Two parts of handling interrupts on multi-processors 1 A method to route interrupts to processors (I/O APIC – Advanced Programmable Interrupt Controller, ioapic.c) 2 A per CPU interrupt controller to handle interrupts (Local APIC, lapic.c) The OS needs to program both the IOAPIC and the LAPIC
  30. 30. IOAPIC • Interrupts are generated by the APIC labelled from IRQ0 to IRQ16 or IRQ24 • A device enables particular interrupts within the IOAPIC table and specifies which processor they should be routed to • For instance, the keyboard interrupt is routed to CPU0 while disk interrupts are routed to CPU(n − 1), where n is the number of CPUs • Every CPU decides whether it wants to receive interrupts. For instance, scheduler() disables all interrupts
  31. 31. IOAPIC • Interrupts are generated by the APIC labelled from IRQ0 to IRQ16 or IRQ24 • A device enables particular interrupts within the IOAPIC table and specifies which processor they should be routed to • For instance, the keyboard interrupt is routed to CPU0 while disk interrupts are routed to CPU(n − 1), where n is the number of CPUs • Every CPU decides whether it wants to receive interrupts. For instance, scheduler() disables all interrupts
  32. 32. IOAPIC • Interrupts are generated by the APIC labelled from IRQ0 to IRQ16 or IRQ24 • A device enables particular interrupts within the IOAPIC table and specifies which processor they should be routed to • For instance, the keyboard interrupt is routed to CPU0 while disk interrupts are routed to CPU(n − 1), where n is the number of CPUs • Every CPU decides whether it wants to receive interrupts. For instance, scheduler() disables all interrupts
  33. 33. IOAPIC • Interrupts are generated by the APIC labelled from IRQ0 to IRQ16 or IRQ24 • A device enables particular interrupts within the IOAPIC table and specifies which processor they should be routed to • For instance, the keyboard interrupt is routed to CPU0 while disk interrupts are routed to CPU(n − 1), where n is the number of CPUs • Every CPU decides whether it wants to receive interrupts. For instance, scheduler() disables all interrupts
  34. 34. LAPIC • Each CPU has its own LAPIC • xv6 programs the LAPIC using lapicinit()
  35. 35. LAPIC • Each CPU has its own LAPIC • xv6 programs the LAPIC using lapicinit()
  36. 36. Example: Timer interrupt • The kernel uses timer interrupts to get a notion of time and to make scheduling decisions • A value of 100 timer ticks is used by default which is high enough to allow interactivity and low enough not to lead to a live lock • This value is set in lapicinit() and IRQ_TIMER is mapped to IRQ0 • IRQ_TIMER corresponds to interrupt number 32 • In trap(), for interrupt number 32, the timer tick is incremented and processes sleeping on it are woken up
  37. 37. Example: Timer interrupt • The kernel uses timer interrupts to get a notion of time and to make scheduling decisions • A value of 100 timer ticks is used by default which is high enough to allow interactivity and low enough not to lead to a live lock • This value is set in lapicinit() and IRQ_TIMER is mapped to IRQ0 • IRQ_TIMER corresponds to interrupt number 32 • In trap(), for interrupt number 32, the timer tick is incremented and processes sleeping on it are woken up
  38. 38. Example: Timer interrupt • The kernel uses timer interrupts to get a notion of time and to make scheduling decisions • A value of 100 timer ticks is used by default which is high enough to allow interactivity and low enough not to lead to a live lock • This value is set in lapicinit() and IRQ_TIMER is mapped to IRQ0 • IRQ_TIMER corresponds to interrupt number 32 • In trap(), for interrupt number 32, the timer tick is incremented and processes sleeping on it are woken up
  39. 39. Example: Timer interrupt • The kernel uses timer interrupts to get a notion of time and to make scheduling decisions • A value of 100 timer ticks is used by default which is high enough to allow interactivity and low enough not to lead to a live lock • This value is set in lapicinit() and IRQ_TIMER is mapped to IRQ0 • IRQ_TIMER corresponds to interrupt number 32 • In trap(), for interrupt number 32, the timer tick is incremented and processes sleeping on it are woken up
  40. 40. Example: Timer interrupt • The kernel uses timer interrupts to get a notion of time and to make scheduling decisions • A value of 100 timer ticks is used by default which is high enough to allow interactivity and low enough not to lead to a live lock • This value is set in lapicinit() and IRQ_TIMER is mapped to IRQ0 • IRQ_TIMER corresponds to interrupt number 32 • In trap(), for interrupt number 32, the timer tick is incremented and processes sleeping on it are woken up
  41. 41. Device Driver • A piece of code in the OS that manages a particular device • Provides interrupt handlers for a device • Causes a device to perform operations • Causes a device to generate interrupts • Non-trivial to write as a driver executes concurrently with the device that it manages • Driver also needs to understand the hardware interface of the device
  42. 42. Device Driver • A piece of code in the OS that manages a particular device • Provides interrupt handlers for a device • Causes a device to perform operations • Causes a device to generate interrupts • Non-trivial to write as a driver executes concurrently with the device that it manages • Driver also needs to understand the hardware interface of the device
  43. 43. Device Driver • A piece of code in the OS that manages a particular device • Provides interrupt handlers for a device • Causes a device to perform operations • Causes a device to generate interrupts • Non-trivial to write as a driver executes concurrently with the device that it manages • Driver also needs to understand the hardware interface of the device
  44. 44. Device Driver • A piece of code in the OS that manages a particular device • Provides interrupt handlers for a device • Causes a device to perform operations • Causes a device to generate interrupts • Non-trivial to write as a driver executes concurrently with the device that it manages • Driver also needs to understand the hardware interface of the device
  45. 45. Device Driver • A piece of code in the OS that manages a particular device • Provides interrupt handlers for a device • Causes a device to perform operations • Causes a device to generate interrupts • Non-trivial to write as a driver executes concurrently with the device that it manages • Driver also needs to understand the hardware interface of the device
  46. 46. Device Driver • A piece of code in the OS that manages a particular device • Provides interrupt handlers for a device • Causes a device to perform operations • Causes a device to generate interrupts • Non-trivial to write as a driver executes concurrently with the device that it manages • Driver also needs to understand the hardware interface of the device
  47. 47. Example: Disk driver • In charge of copying data back and forth from the disk • Data is represented on the disk as a sequence of sectors, each containing 512-byte blocks • Sector 0 represents the first 512 bytes, sector 1 the next 512, and so on • The OS has a corresponding structure (struct buf) that maps to one sector • The data within the OS sector structure is often out of sync with the disk • xv6 implements an IDE driver
  48. 48. Example: Disk driver • In charge of copying data back and forth from the disk • Data is represented on the disk as a sequence of sectors, each containing 512-byte blocks • Sector 0 represents the first 512 bytes, sector 1 the next 512, and so on • The OS has a corresponding structure (struct buf) that maps to one sector • The data within the OS sector structure is often out of sync with the disk • xv6 implements an IDE driver
  49. 49. Example: Disk driver • In charge of copying data back and forth from the disk • Data is represented on the disk as a sequence of sectors, each containing 512-byte blocks • Sector 0 represents the first 512 bytes, sector 1 the next 512, and so on • The OS has a corresponding structure (struct buf) that maps to one sector • The data within the OS sector structure is often out of sync with the disk • xv6 implements an IDE driver
  50. 50. Example: Disk driver • In charge of copying data back and forth from the disk • Data is represented on the disk as a sequence of sectors, each containing 512-byte blocks • Sector 0 represents the first 512 bytes, sector 1 the next 512, and so on • The OS has a corresponding structure (struct buf) that maps to one sector • The data within the OS sector structure is often out of sync with the disk • xv6 implements an IDE driver
  51. 51. Example: Disk driver • In charge of copying data back and forth from the disk • Data is represented on the disk as a sequence of sectors, each containing 512-byte blocks • Sector 0 represents the first 512 bytes, sector 1 the next 512, and so on • The OS has a corresponding structure (struct buf) that maps to one sector • The data within the OS sector structure is often out of sync with the disk • xv6 implements an IDE driver
  52. 52. Example: Disk driver • In charge of copying data back and forth from the disk • Data is represented on the disk as a sequence of sectors, each containing 512-byte blocks • Sector 0 represents the first 512 bytes, sector 1 the next 512, and so on • The OS has a corresponding structure (struct buf) that maps to one sector • The data within the OS sector structure is often out of sync with the disk • xv6 implements an IDE driver
  53. 53. Code: struct buf struct buf { int flags; uint dev; uint sector; struct buf *prev; struct buf *next; struct buf *qnext; uchar data[512]; }; #define B_BUSY 0x1 #define B_VALID 0x2 #define B_DIRTY 0x4
  54. 54. Example: Disk driver initialization • ideinit() is invoked by main(), which initializes the disk driver 1 ideinit() sets up CPU(n − 1) to handle disk interrupts 2 It then makes a call to idewait() to wait for disk 0 to initialize • It assumes that at least disk 0 is present because the boot loader and the kernel were obviously loaded from it 3 idewait() polls the status bits of the disk hardware, until IDE_BSY is clear and IDE_DRDY is set 4 It then checks whether another disk is present
  55. 55. Example: Disk driver initialization • ideinit() is invoked by main(), which initializes the disk driver 1 ideinit() sets up CPU(n − 1) to handle disk interrupts 2 It then makes a call to idewait() to wait for disk 0 to initialize • It assumes that at least disk 0 is present because the boot loader and the kernel were obviously loaded from it 3 idewait() polls the status bits of the disk hardware, until IDE_BSY is clear and IDE_DRDY is set 4 It then checks whether another disk is present
  56. 56. Example: Disk driver initialization • ideinit() is invoked by main(), which initializes the disk driver 1 ideinit() sets up CPU(n − 1) to handle disk interrupts 2 It then makes a call to idewait() to wait for disk 0 to initialize • It assumes that at least disk 0 is present because the boot loader and the kernel were obviously loaded from it 3 idewait() polls the status bits of the disk hardware, until IDE_BSY is clear and IDE_DRDY is set 4 It then checks whether another disk is present
  57. 57. Example: Disk driver initialization • ideinit() is invoked by main(), which initializes the disk driver 1 ideinit() sets up CPU(n − 1) to handle disk interrupts 2 It then makes a call to idewait() to wait for disk 0 to initialize • It assumes that at least disk 0 is present because the boot loader and the kernel were obviously loaded from it 3 idewait() polls the status bits of the disk hardware, until IDE_BSY is clear and IDE_DRDY is set 4 It then checks whether another disk is present
  58. 58. Example: Disk driver initialization • ideinit() is invoked by main(), which initializes the disk driver 1 ideinit() sets up CPU(n − 1) to handle disk interrupts 2 It then makes a call to idewait() to wait for disk 0 to initialize • It assumes that at least disk 0 is present because the boot loader and the kernel were obviously loaded from it 3 idewait() polls the status bits of the disk hardware, until IDE_BSY is clear and IDE_DRDY is set 4 It then checks whether another disk is present
  59. 59. Example: Disk driver initialization • ideinit() is invoked by main(), which initializes the disk driver 1 ideinit() sets up CPU(n − 1) to handle disk interrupts 2 It then makes a call to idewait() to wait for disk 0 to initialize • It assumes that at least disk 0 is present because the boot loader and the kernel were obviously loaded from it 3 idewait() polls the status bits of the disk hardware, until IDE_BSY is clear and IDE_DRDY is set 4 It then checks whether another disk is present
  60. 60. Buffer cache • The buffer cache is a linked list of struct buf in memory • It holds cached copies of disk blocks • Uses iderw(struct buf *b) to read/write a buffer from/to the disk • If B_DIRTY is set, it writes b to disk • If B_VALID is not set, it reads b from disk
  61. 61. Buffer cache • The buffer cache is a linked list of struct buf in memory • It holds cached copies of disk blocks • Uses iderw(struct buf *b) to read/write a buffer from/to the disk • If B_DIRTY is set, it writes b to disk • If B_VALID is not set, it reads b from disk
  62. 62. Buffer cache • The buffer cache is a linked list of struct buf in memory • It holds cached copies of disk blocks • Uses iderw(struct buf *b) to read/write a buffer from/to the disk • If B_DIRTY is set, it writes b to disk • If B_VALID is not set, it reads b from disk
  63. 63. Buffer cache • The buffer cache is a linked list of struct buf in memory • It holds cached copies of disk blocks • Uses iderw(struct buf *b) to read/write a buffer from/to the disk • If B_DIRTY is set, it writes b to disk • If B_VALID is not set, it reads b from disk
  64. 64. Buffer cache • The buffer cache is a linked list of struct buf in memory • It holds cached copies of disk blocks • Uses iderw(struct buf *b) to read/write a buffer from/to the disk • If B_DIRTY is set, it writes b to disk • If B_VALID is not set, it reads b from disk
  65. 65. iderw • Disk accesses take milliseconds of time therefore polling is not an option • iderw keeps the list of pending disk requests in a queue (idequeue) and uses interrupts to signal whenever a request has finished • It adds b to the end of idequeue • If b is the only buffer in idequeue, it instantly dispatches it to the disk hardware by calling idestart() which either issues a read or a write • The current process is then put to sleep waiting for the operation on b to be completed • Once the hardware has completed the operation, it will generate an interrupt (IRQ_IDE) which will be handled by trap by invoking ideintr()
  66. 66. iderw • Disk accesses take milliseconds of time therefore polling is not an option • iderw keeps the list of pending disk requests in a queue (idequeue) and uses interrupts to signal whenever a request has finished • It adds b to the end of idequeue • If b is the only buffer in idequeue, it instantly dispatches it to the disk hardware by calling idestart() which either issues a read or a write • The current process is then put to sleep waiting for the operation on b to be completed • Once the hardware has completed the operation, it will generate an interrupt (IRQ_IDE) which will be handled by trap by invoking ideintr()
  67. 67. iderw • Disk accesses take milliseconds of time therefore polling is not an option • iderw keeps the list of pending disk requests in a queue (idequeue) and uses interrupts to signal whenever a request has finished • It adds b to the end of idequeue • If b is the only buffer in idequeue, it instantly dispatches it to the disk hardware by calling idestart() which either issues a read or a write • The current process is then put to sleep waiting for the operation on b to be completed • Once the hardware has completed the operation, it will generate an interrupt (IRQ_IDE) which will be handled by trap by invoking ideintr()
  68. 68. iderw • Disk accesses take milliseconds of time therefore polling is not an option • iderw keeps the list of pending disk requests in a queue (idequeue) and uses interrupts to signal whenever a request has finished • It adds b to the end of idequeue • If b is the only buffer in idequeue, it instantly dispatches it to the disk hardware by calling idestart() which either issues a read or a write • The current process is then put to sleep waiting for the operation on b to be completed • Once the hardware has completed the operation, it will generate an interrupt (IRQ_IDE) which will be handled by trap by invoking ideintr()
  69. 69. iderw • Disk accesses take milliseconds of time therefore polling is not an option • iderw keeps the list of pending disk requests in a queue (idequeue) and uses interrupts to signal whenever a request has finished • It adds b to the end of idequeue • If b is the only buffer in idequeue, it instantly dispatches it to the disk hardware by calling idestart() which either issues a read or a write • The current process is then put to sleep waiting for the operation on b to be completed • Once the hardware has completed the operation, it will generate an interrupt (IRQ_IDE) which will be handled by trap by invoking ideintr()
  70. 70. iderw • Disk accesses take milliseconds of time therefore polling is not an option • iderw keeps the list of pending disk requests in a queue (idequeue) and uses interrupts to signal whenever a request has finished • It adds b to the end of idequeue • If b is the only buffer in idequeue, it instantly dispatches it to the disk hardware by calling idestart() which either issues a read or a write • The current process is then put to sleep waiting for the operation on b to be completed • Once the hardware has completed the operation, it will generate an interrupt (IRQ_IDE) which will be handled by trap by invoking ideintr()
  71. 71. Code: iderw void iderw(struct buf *b) { struct buf **pp; acquire(&idelock); b->qnext = 0; for(pp=&idequeue; *pp; pp=&(*pp)->qnext) ; *pp = b; if(idequeue == b) idestart(b); while((b->flags & (B_VALID|B_DIRTY)) != B_VALID){ sleep(b, &idelock); } release(&idelock); }
  72. 72. ideintr 1 Checks the first buffer in idequeue to find the type of the operation (read or write) 2 If the operation was a read, it reads the data into the buffer via insl() 3 It then sets B_VALID and clears B_DIRTY and wakes up any processes sleeping on b 4 Finally, it dispatches the next buffer from idequeue
  73. 73. ideintr 1 Checks the first buffer in idequeue to find the type of the operation (read or write) 2 If the operation was a read, it reads the data into the buffer via insl() 3 It then sets B_VALID and clears B_DIRTY and wakes up any processes sleeping on b 4 Finally, it dispatches the next buffer from idequeue
  74. 74. ideintr 1 Checks the first buffer in idequeue to find the type of the operation (read or write) 2 If the operation was a read, it reads the data into the buffer via insl() 3 It then sets B_VALID and clears B_DIRTY and wakes up any processes sleeping on b 4 Finally, it dispatches the next buffer from idequeue
  75. 75. ideintr 1 Checks the first buffer in idequeue to find the type of the operation (read or write) 2 If the operation was a read, it reads the data into the buffer via insl() 3 It then sets B_VALID and clears B_DIRTY and wakes up any processes sleeping on b 4 Finally, it dispatches the next buffer from idequeue
  76. 76. Modern disk controllers in a real OS • Most disk controllers typically accept multiple outstanding disk requests at a time • They even reorder them to make efficient use of the disk arm • Conceptually other hardware is very similar to disks • Network buffers hold packets • Audio device buffers hold sound samples • Graphics card buffers hold video data
  77. 77. Modern disk controllers in a real OS • Most disk controllers typically accept multiple outstanding disk requests at a time • They even reorder them to make efficient use of the disk arm • Conceptually other hardware is very similar to disks • Network buffers hold packets • Audio device buffers hold sound samples • Graphics card buffers hold video data
  78. 78. Modern disk controllers in a real OS • Most disk controllers typically accept multiple outstanding disk requests at a time • They even reorder them to make efficient use of the disk arm • Conceptually other hardware is very similar to disks • Network buffers hold packets • Audio device buffers hold sound samples • Graphics card buffers hold video data
  79. 79. Modern disk controllers in a real OS • Most disk controllers typically accept multiple outstanding disk requests at a time • They even reorder them to make efficient use of the disk arm • Conceptually other hardware is very similar to disks • Network buffers hold packets • Audio device buffers hold sound samples • Graphics card buffers hold video data
  80. 80. Modern disk controllers in a real OS • Most disk controllers typically accept multiple outstanding disk requests at a time • They even reorder them to make efficient use of the disk arm • Conceptually other hardware is very similar to disks • Network buffers hold packets • Audio device buffers hold sound samples • Graphics card buffers hold video data
  81. 81. Modern disk controllers in a real OS • Most disk controllers typically accept multiple outstanding disk requests at a time • They even reorder them to make efficient use of the disk arm • Conceptually other hardware is very similar to disks • Network buffers hold packets • Audio device buffers hold sound samples • Graphics card buffers hold video data
  82. 82. DMA • High-bandwidth I/O devices, such as disks, graphics cards, network cards, etc. often use direct memory access (DMA) instead of explicit I/O (insl and outsl) • Via DMA, controllers get direct access to physical memory • The device driver passes the physical address of the buffer’s data field to the device, which copies it from/to the main memory • Once it is done, it generates an interrupt • As a result of DMA, the CPU is not involved, hence making the entire process more efficient
  83. 83. DMA • High-bandwidth I/O devices, such as disks, graphics cards, network cards, etc. often use direct memory access (DMA) instead of explicit I/O (insl and outsl) • Via DMA, controllers get direct access to physical memory • The device driver passes the physical address of the buffer’s data field to the device, which copies it from/to the main memory • Once it is done, it generates an interrupt • As a result of DMA, the CPU is not involved, hence making the entire process more efficient
  84. 84. DMA • High-bandwidth I/O devices, such as disks, graphics cards, network cards, etc. often use direct memory access (DMA) instead of explicit I/O (insl and outsl) • Via DMA, controllers get direct access to physical memory • The device driver passes the physical address of the buffer’s data field to the device, which copies it from/to the main memory • Once it is done, it generates an interrupt • As a result of DMA, the CPU is not involved, hence making the entire process more efficient
  85. 85. DMA • High-bandwidth I/O devices, such as disks, graphics cards, network cards, etc. often use direct memory access (DMA) instead of explicit I/O (insl and outsl) • Via DMA, controllers get direct access to physical memory • The device driver passes the physical address of the buffer’s data field to the device, which copies it from/to the main memory • Once it is done, it generates an interrupt • As a result of DMA, the CPU is not involved, hence making the entire process more efficient
  86. 86. DMA • High-bandwidth I/O devices, such as disks, graphics cards, network cards, etc. often use direct memory access (DMA) instead of explicit I/O (insl and outsl) • Via DMA, controllers get direct access to physical memory • The device driver passes the physical address of the buffer’s data field to the device, which copies it from/to the main memory • Once it is done, it generates an interrupt • As a result of DMA, the CPU is not involved, hence making the entire process more efficient
  87. 87. Dynamic interrupt routing • In case of xv6 all disk interrupts are routed to CPU(n − 1) • Real OSes use sophisticated algorithms to dynamically route interrupts to processors • The goal is to achieve optimum load balancing while maintaining good locality
  88. 88. Dynamic interrupt routing • In case of xv6 all disk interrupts are routed to CPU(n − 1) • Real OSes use sophisticated algorithms to dynamically route interrupts to processors • The goal is to achieve optimum load balancing while maintaining good locality
  89. 89. Dynamic interrupt routing • In case of xv6 all disk interrupts are routed to CPU(n − 1) • Real OSes use sophisticated algorithms to dynamically route interrupts to processors • The goal is to achieve optimum load balancing while maintaining good locality
  90. 90. Reading(s) • Chapter 3, “Traps, interrupts, and drivers”, section “Code: Interrupts" onwards from “xv6: a simple, Unix-like teaching operating system”

×