In previous article we got our CPU into 64 bit mode and were able to run 64 bit programs. Our vCPU is already very useful but it doesn't deal well with issues like division by zero, page faults or other exceptional cases it might encounter. Division by zero and page faults are examples of exceptions. Exceptions can happen at any point in time during operation of the processor and they signify an event that needs attention of the processor. Because the idea of this series of posts is learning we will focus on one of the simpler exceptions - division by zero. After working through this article you should be able to extend the code to handle other exceptions, interrupts or traps. Triggering interrupts Division by zero can be solved in software by first checking if divider is equal to zero. If it is, we use INT instruction to trigger an exception. It can also be triggered by CPU automatically. In case of software generated interrupt it's up to us to decide which interrupt handler to use to deal with divide by zero issue. When CPU triggers the handler it choses handler at predefined location. Exception handlers are normally found via so called Interrupt Descriptor Table or IDT for short. IDT contains up to 256 entries and each of those entries is 16 bytes in size in 64 bit mode. When using software interrupts we can choose any of the entries to place our exception handler but it is customary to have "divide by zero" error as the first entry (index = 0). It also allows us to use the same handler for software generated interrupt as well as hardware generated one. When an interrupt is invoked it looks up the corresponding entry in IDT to find the location of interrupt handler. As you will see a little bit later, IDT entry defines which code segment to use. In our case we only have one code segment so it may not seem so important but It does imply that we need to set up a so called Global Descriptor Table (GDT). GDT is used by CPU to select code segment specified in an IDT entry. Building on the work from previous articles we will define a GDT, then we will define IDT and a handler. Finally we will load a program to trigger the exception handler. Full code is available at Gitlab: . As you read this article I suggest you follow the code too. It should help you learn these concepts faster. https://gitlab.com/mvuksano/kvm-playground/-/tree/master/07-exceptions Global Descriptor Table Global descriptor table is a data structure that is present on x86 processors and it is used to configure characteristics of various memory areas. It is used in real and protected mode but it is almost not used in long mode. In long mode GDT is generally set up once during startup and never changed again. GDT was used to configure characteristics of different memory segments. Memory segments are selected via so called segment selectors which are in turned stored in segment registers. For example, CS or code segment register could contain value 0x8. 0x8 is segment selector as it "selects" byte in GDT which, in this example, should be location of code segment descriptor. 0x8 In long mode segmentation is disabled but CPU still uses some fields from segment selector (e.g. Descriptor Privilege Level or DPL field from Code Segment). For example, instruction will also throw General Protection Exception in case referenced code segment is not valid. This means that we can't totally ignore GDT and have to do a little bit of setup. int To enable CPU to handle interrupts, exceptions and traps we need to set up two entries in our GDT: Null descriptor Code Segment descriptor GDT entries are 8 bytes in size. Null descriptor is a sequence of zeros. GDT always has null descriptor as its first entry. Code segment descriptor is used, in long mode, to establish processor's operating mode and executing privilege level. Majority of bits in CS descriptor are ignored but there are a few that we need to set. The following image is from Intel manual and shows which bits mean what and which ones are ignored: First 5 bytes as well as the last byte need to be set to 0. This means we really only care about two bytes in the "middle" - the ones that fall in range 8-15 and 16-23. For byte that starts at position 40 (indicated by number 8 in top row in the image above): Bit P needs to be set to 1 to indicate that this segment is present DPL (Descriptor Privilege Level) should be set to 0x00. This is the highest privilege level. Bits 12 is always set to 1 Type for code segment should be set to 0xa (You can check table 3-1 from Intel Manual for other code and data segment types) And for bits 51 - 54 (4 bits starting at number 20 in top row in the image above): For 64 bit code segment bit L needs to be set. When L bit is set, D bit has to be 0 Bit G should not be relevant in 64 bit mode. It tells how field in CS is interpreted but given limit field is ignored in 64 bit mode we should be able to set this to anything. In this example I have set this bit. Given the above information our first byte (we'll call it byte) can be set to and the second byte (we'll call it byte) should be set to . type 0x9a flags 0xa0 All other bytes should be set to . 0 Define GDT entries There are numerous ways to define GDT entries. The following is just one possible solution. We will define two structs and . struct gdtNullEntry struct gdtEntry can be defined using a struct that contains 8 bytes all set to zero. For example: gdtNullEntry always0[ ];
} __attribute__((packed)); { struct gdtNullEntry unsigned char 8 is a little bit more complex. It has 5 byte padding at the beginning and 2 byte padding at the end. In the middle are two bytes called and : gdtEntry type flags padding_1[ ]; type; flags; padding_2[ ];
} __attribute__((packed)); { struct gdtEntry unsigned char 5 unsigned char unsigned char unsigned char 2 Interrupt Descriptor Table Interrupt descriptor table (IDT) is a table of descriptors that are used map interrupts to interrupt handlers. This table has up to 256 entries and each of the entries is 16 bytes large. Address of IDT is stored in register. idtr In case of an exception CPU will consult the table and call interrupt handler associated with the exception. There are a few different types of exceptions but we won't discuss them in this article. Hopefully, I'll find some time in the future to talk a bit more about it. In 64 bit mode, IDT entries are encoded using the following data structure: is memory address at which interrupt handler can be found. Offset is used to tell CPU which code segment to use when looking for interrupt handler. As we already mentioned when talking about GDT, in 64 bit mode CS is not used for address calculations. It is used to enforce privilege checks which we won't discuss at this point. For now we  are working at the highest privilege level - 0. Segment selector Type field is used to tell CPU what kind of handler this descriptor points to. Depending on the type CPU might do slightly different things. In this example we will use what is called an "interrupt gate" and type field for that gate is 0xe. (IST) is used to enable interrupt to always execute on a known good stack. For now we will set it to . Interrupt stack table 0x0 As with GDT entires, there are numerous ways to define IDT entries. In this example I'll use the following data structure to encode an IDT entry: base_lo; sel; always0; flags; base_hi; padding[ ];
} __attribute__((packed)); { struct idt_entry unsigned short unsigned short unsigned char unsigned char unsigned short unsigned char 8 The first two bytes ( ) are the two least significant bytes of the address where the interrupt handler is located. The next two bytes are used to specify which code segment descriptor to use. In our case we have only one code segment and it can be found starting at byte 8 in GDT. base_lo byte must always be set to 0. is used to encode a bit more information about segment selector (higher 4 bytes) and specify what kind of interrupt handler this descriptor points to (lower 4 bytes). always0 flags In our case this byte will have value . The highest 8 bytes will be set to 0 in our case. represents 3rd and 4th byte of interrupt handler address. 0x8e base_hi Create and loading GDT and IDT So far we have defined data structures that can be used to create GDT and IDT. Creating the tables is a matter of initializing those data structures and copying them into memory at correct locations: { .type = ,
		.flags = }; (mem, &nullEntry, ); (mem + , &csEntry, );
} void createGdtTable ( *mem) void ; struct gdtNullEntry nullEntry = { struct gdtEntry csEntry 0x9a 0xa0 memcpy 8 memcpy 8 8 GDT entries are 8 bytes in size so function copies nullEntry at the location pointed to by while is copied right after. createGdtTable mem csEntry To create the IDT table we use function: createIdtTable { .base_lo = ,
		.sel = ,
		.flags = ,
	}; ( i = ; i < ; i++) { (mem + i * , &e, );
	}
} void createIdt ( *mem) void = { struct idt_entry e 0x9000 0x8 0x8e for int 0 256 memcpy 16 16 This function populates 256 IDT entries and points them to the same handler. Keep in mind that IDT entries are 16 bytes in size compared to GDT which are 8 bytes large. In the main function we use and to place GDT and IDT at desired memory locations. For this tutorial I've chosen to place GDT at memory location and IDT at . createGdtTable createIdtTable 0x0 0xc000 Also keep in mind that these are virtual addresses which happen to be identity mapped in this set of articles. createGdtTable(mem);
createIdt(mem + ); 0xc000 Interrupt handler function Next missing piece in the puzzle is an actual interrupt handler: , , , BITS 64 mov rax 'H' mov edx 0x3f8 out dx al hlt The interrupt handler is super simple - it just outputs letter H and exits the VM. Run a program and trigger handler There are multiple ways to trigger an interrupt handler. In this example we will use instruction. It is used to trigger an interrupt handler from a program. int The instruction itself takes a number which tells which of the handlers to use. for example will trigger the first interrupt (interrupts are zero indexed). int 0 Calling something like would trigger 58th interrupt. int 57 We will use the following program to trigger the interrupt: , , , , BITS 64 mov esp 0xe000 mov rax 'N' mov edx 0x3f8 out dx al int 0 hlt An astute reader will notice that the first instruction in this program actually sets stack pointer (ESP) to . The reason why we need to set a stack pointer to some known good value is because when the interrupt handler is called CPU will place return address on the stack. 0xe000 The return address is (in this case) next instruction to execute. Following that we output character "N" and trigger interrupt handler 0. Our interrupt handler just halts the VM and doesn't do anything but in normal operation an interrupt handler would continue executing a program. When you run the program you should see the following output: And that is it! You now have a vCPU that is configured to handle interrupts and exceptions Conclusion In this series of articles we've worked our way and configured a CPU that runs in 64bit mode and can handle interrupts and exceptions. This is good enough base for running some workloads in a VM as well as a good staring point to write your own OS. If you followed the my series you can see that there are quite a few moving pieces to put together. Hopefully now you have enough knowledge to drill down even further and adapt this code to your needs. Stay tuned to learn what other cool stuff you can do with VMs and CPUs. References [1] Section 5.5, “Privilege Levels”, for a description of the relationship of the DPL to the CPL

Assembly

Intel

Super

x86 Handling Exceptions

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

16/32/64 Bit Assembly Programs

How to Enable 64bit Mode on x86

16/32/64 Bit Assembly Programs

Adventures in Assembly #1 [How It Usually Begins]

Adventures in Assembly #2

16/32/64 Bit Assembly Programs

How to Enable 64bit Mode on x86

16/32/64 Bit Assembly Programs

Adventures in Assembly #1 [How It Usually Begins]

Adventures in Assembly #2

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps