36. I/O Devices. Operating System: Three Easy Pieces 1

Transcription

1 36. I/O Devices Oerating System: Three Easy Pieces 1

2 I/O Devices I/O is critical to comuter system to interact with systems. Issue : w How should I/O be integrated into systems? w What are the general mechanisms? w How can we make the efficiently? AOS@UC 2

3 Structure of inut/outut (I/O) device CPU Memory Seed+ & Cost+ Grahics Memory Bus (rorietary) General I/O Bus (e.g., PCI) Periheral I/O Bus (e.g., SCSI, SATA, USB) Prototyical System Architecture CPU is attached to the main memory of the system via some kind of memory bus. Some devices are connected to the system via a general I/O bus. Why not a flat design? (like in the early days) AOS@UC 3

4 I/O Architecture Buses w Data aths that rovided to enable information between CPU(s), RAM, and I/O devices. I/O bus w Data ath that connects a CPU to an I/O device. w I/O bus is connected to I/O device by three hardware comonents: I/O orts, interfaces and device controllers. In current system (due to scalability limitations of the buses) some high-seed buses have migrated to oint-to-oint networks AOS@UC 4

5 Canonical Device Canonical Devices has two imortant comonents. w Hardware interface allows the system software to control its oeration. w Internals which is imlementation secific. Registers: Status Command Data interface Micro-controller(CPU) Memory (DRAM or SRAM or both) Other Hardware-secific Chis Internals (HW+SW) Canonical Device AOS@UC 5

6 Hardware interface of Canonical Device status register w See the current status of the device command register w Tell the device to erform a certain task data register w Pass data to the device, or get data from the device By reading and writing above three registers, the oerating system can control device behavior. AOS@UC 6

7 Hardware interface of Canonical Device (Cont.) Tyical interaction examle (Programmed I/O or PIO) while ( STATUS == BUSY) ; //wait until device is not busy write data to data register write command to command register Doing so starts the device and executes the command while ( STATUS == BUSY) ; //wait until device is done with your request AOS@UC 7

8 Polling Oerating system waits until the device is ready by reeatedly reading the status register. w Positive asect is simle and working. w However, it wastes CPU time just waiting for the device. Switching to another ready rocess is better utilizing the CPU. waiting IO 1 : task 1 P : olling CPU Disk Diagram of CPU utilization by olling AOS@UC 8

9 interruts Put the I/O request rocess to slee and context switch to another. When the device is finished, wake the rocess waiting for the I/O by interrut (via interrut handler or Interrut Service Routine ISR) w Positive asect is allow to CPU and the disk are roerly utilized. 1 : task 1 2 : task 2 CPU Disk Diagram of CPU utilization by interrut AOS@UC 9

10 Polling vs interruts However, interruts is not always the best solution w If, device erforms very quickly (for examle, at first oll the oeration is done), interrut will slow down the system. w Because context switch is exensive (switching to another rocess) If a device is fast à oll is best. If it is slow à interruts is better. Hybrid aroach w If oll too slow go to interruts Coalescing interruts AOS@UC 10

11 CPU is once again over-burdened CPU wastes a lot of time to coy the a large chunk of data from memory to the device. over-burdened 1 : task 1 2 : task 2 C : coy data from memory CPU C C C Disk Diagram of CPU utilization AOS@UC 11

12 DMA (Direct Memory Access) Coy data in memory by knowing where the data lives in memory, & how much data to coy Tell the DMA controller to do the hard-work When comleted, DMA raises an interrut, I/O begins on Disk. 1 : task 1 2 : task 2 C : coy data from memory CPU DMA C C C Disk Diagram of CPU utilization by DMA AOS@UC 12

13 Device interaction How the CPU communicates with the device? Aroaches w I/O instructions: a way for the OS to send data to secific device registers. Ex) in and out instructions on x86 Searate I/O and memory buses in early days w memory-maed I/O Device registers available as if they were memory locations. The OS load (to read) or store (to write) to the device instead of main memory. AOS@UC 13

14 Fitting Into The OS: The Device Driver How the OS interact with different secific interfaces? w Ex) We d like to build a file system that worked on to of SCSI disks, IDE disks, USB keychain drivers, and so on. Solution: Abstraction w Abstraction encasulate any secifics of device interaction. w Only the lowest level should be aware of the secifics: called Device driver AOS@UC 14

15 File system Abstraction File system secifics of which disk class it is using. w Ex) It issues block read and write request to the generic block layer. Alication user POSIX API [oen, read, write, close, etc] File System kernel Generic Block Interface [block read/write] Generic Block Layer Device Driver [SCSI, ATA, etc] Secific Block Interface [rotocol-secific read/write] The File System Stack AOS@UC 15

16 Problem of File system Abstraction If there is a device having many secial caabilities, these caabilities will go unused in the generic interface layer. w Ex) SCSI devices have a rich error reorting that are mostly unused in Linux because IDE/ATA had very limited caabilities Over 70% of OS code is found in device drivers. w Any device drivers are needed because you might lug it to your system. w They are rimary contributor to kernel crashes, making more bugs. w Device signing in current windows system has imroved its resiliency greatly AOS@UC 16

17 Case Study: A Simle IDE Disk Driver (xv6 uses QEMU IDE) Four tyes of register w Control, command block, status and error w Maed to I/O addresses w in and out I/O instruction Book code doesn't not match with current version AOS@UC 17

18 Control Register: Address 0x3F6 = 0x80 (0000 1RE0): R=reset, E=0 means "enable interrut Command Block Registers: Address 0x1F0 = Data Port Address 0x1F1 = Error Address 0x1F2 = Sector Count Address 0x1F3 = LBA low byte (Logical Block Address) Address 0x1F4 = LBA mid byte Address 0x1F5 = LBA hi byte Address 0x1F6 = 1B1D TOP4LBA: B=LBA, D=drive Address 0x1F7 = Command/status AOS@UC 18

19 Status Register (Address 0x1F7): BUSY READY FAULT SEEK DRQ CORR IDDEX ERROR Error Register (Address 0x1F1): (check when Status ERROR==1) BBK UNC MC IDNF MCR ABRT T0NF AMNF w w w w w w w w BBK = Bad Block UNC = Uncorrectable data error MC = Media Changed IDNF = ID mark Not Found MCR = Media Change Requested ABRT = Command aborted T0NF = Track 0 Not Found AMNF = Address Mark Not Found AOS@UC 19

20 Wait for drive to be ready. Read Status Register (0x1F7) until drive is not busy and READY. Write arameters to command registers. Write the sector count, logical block address (LBA) of the sectors to be accessed, and drive number (master=0x00 or slave=0x10, as IDE ermits just two drives) to command registers (0x1F2-0x1F6). Start the I/O. by issuing read/write to command register. Write READ WRITE command to command register (0x1F7). Data transfer (for writes): Wait until drive status is READY and DRQ (drive request for data); write data to data ort. Handle interruts. In the simlest case, handle an interrut for each sector transferred; more comlex aroaches allow batching and thus one final interrut when the entire transfer is comlete. Error handling. After each oeration, read the status register. If the ERROR bit is on, read the error register for details. 20

21 xv6: I/O buffer (node struct) struct buf { int flags; uint dev; uint sector; struct buf *rev; // LRU cache list struct buf *next; struct buf *qnext; // disk queue uchar data[512]; }; #define B_BUSY 0x1 // buffer is locked by some rocess #define B_VALID 0x2 // buffer has been read from disk #define B_DIRTY 0x4 // buffer needs to be written to disk AOS@UC 21

22 xv6 code: Queues request (if IDE not avail) or issue the req. void ide_rw(struct buf *b) { acquire(&ide_lock); for (struct buf ** = &ide_queue; *; =&(*)->qnext) ; // walk queue (beware 2 nd term) * = b; // add request to end if (ide_queue == b) // if q was emty (only has b) ide_start_request(b); // send req to disk while ((b->flags & (B_VALID B_DIRTY))!= B_VALID) slee(b, &ide_lock); // wait for comletion and rel. lock release(&ide_lock); } AOS@UC 22

23 xv6 code: intercedes with the driver static void ide_start_request(struct buf *b) { ide_wait_ready(); outb(0x3f6, 0); outb(0x1f2, 1); // generate interrut // how many sectors to read/write? outb(0x1f3, b->sector & 0xff); // LBA goes here... outb(0x1f4, (b->sector >> 8) & 0xff); //... and here outb(0x1f5, (b->sector >> 16) & 0xff); //... and here! outb(0x1f6, 0xe0 ((b->dev & 1)<<4) ((b->sector>>24) & 0x0f)); //M or S? if(b->flags & B_DIRTY){ outb(0x1f7, IDE_CMD_WRITE); outsl(0x1f0, b->data, 512/4); // this is a WRITE // transfer data too! } else { outb(0x1f7, IDE_CMD_READ); // this is a READ (no data) } } AOS@UC 23

24 xv6 code: just check the device is ready and not busy static int ide_wait_ready() { while (((int r = inb(0x1f7)) & IDE_BSY)!(r & IDE_DRDY)) ; // loo until drive isn t busy } Device should be initialized somewhere else (at boot) AOS@UC 24

25 xv6 code: interrut handler void ide_intr() { struct buf *b; acquire(&ide_lock); //take b as the first element in the ide_queue (not shown) if (!(b->flags & B_DIRTY) && ide_wait_ready(1) >= 0) insl(0x1f0, b->data, 512/4); // if READ: get data b->flags = B_VALID; b->flags &= B_DIRTY; wakeu(b); // wake waiting rocess (equivalent to signal) if ((ide_queue = b->qnext)!= 0) // start next request ide_start_request(ide_queue); // (if one exists) release(&ide_lock); } AOS@UC 25

26 Current xv6 code (kernel/ide.c) 26

27 27

28 Disclaimer: This lecture slide set has been used in AOS course at University of Cantabria by V.Puente. Was initially develoed for Oerating System course in Comuter Science Det. at Hanyang University. This lecture slide set is for OSTEP book written by Remzi and Andrea Araci-Dusseau (at University of Wisconsin) 28