OSDev.org

How do I get QEMU to give me a prompt? Currently I run qemu and it immediately boots into my OS and then crashes. This is the command I use.

I think with the new code I have 48 IRQs, but I could be wrong. How do I fix my exception handlers? I thought that's what the IRQs did, exception and interrupt handling.

As Octocontrabass said, you can't access CS directly. Use the following code to change it (it's in AT&T syntax because I don't know how the operand sizes work in Intel's syntax for these instructions):


You can't handle exceptions and IRQs with the exact same code. Each interrupt serves a different purpose.
In my OS, I have one IRQ handler and one exception handler, both written in C (actually C++ but I don't use any C++ features except classes). These two handlers are called by small assembly handlers, one for each interrupt. The assembly handlers push all the registers and call the handlers, giving them the interrupt's number and an error code (if the exception has one). The C handlers call a thread that handles the exception/IRQ. After the C handler returns, the assembly handler pops all the registers and returns (iret).
For now, I think your exception handler could just print some exception info and then hang ('jmp $').

Also, about your 'long_mode_start' function, I don't understand it. Where and when do you load the GDT? And why do you still set the segment registers to 0?
Besides that, you don't need to push rsp in your handler. The interrupt does it by itself. And since you'll probably push all the registers a few more times in your code, I'd recommend you create a 'pusha' macro.

The Windows builds of QEMU include a GUI with a convenient menu to switch between them, but the QEMU documentation says you can use keyboard shortcuts to switch to the monitor too.


You have 16 IRQs. IRQs are interrupt requests that come from hardware external to the CPU core. The CPU core itself can also generate 32 exceptions. All together, that's 48 interrupts, which requires at least 48 entries in your IDT, and 48 ISRs to handle all of them.

If you get the terminology wrong, you'll definitely be confused.

Alright I changed the code and now load CS properly, thank you.

So I understand what you're saying, but I just don't know how to implement it. Right now I use the loop that you recommended in a previous answer.

So this should make all 48 entries in my IDT? If this is correct, what am I missing? I apologize ahead of time for my lack of knowledge.
Here is the whole main64.asm file.


My GDT is loaded in main.asm when the OS is still in protected mode. I then make a long jump in order to reach long_mode_start after switching to long mode. The segment registers were set to 0 because that is how it was explained to me in a tutorial, I have no other reason. I've taken out that part as of now. Here is the GDT code from the other file.

And the GDT is loaded like this in the start function:


Thank you, I finally got the prompt.

The code will set all entries to a specific handler. You can use it now for your exceptions, but you'll need to give each interrupt its own handler at some point. And here the disadvantage of my method reveals itself - writing a handler for each interrupt and then configuring each interrupt separately requires lots of code. I use a simple python script to generate the code, but still, it's very messy and can be confusing. Maybe someone else has a better idea.

Now to your code. Since you create and load the GDT in protected mode, you don't need to change CS (CS is changed when you switch to long mode). However, you do need to change the data segment registers. It looks like you don't fully understand the segment selectors, so I'll explain them:
Each selector is made out of 3 parts: the privilege, the table index, and the descriptor index. In a C struct, the selector would look like this:

So, for your data segment descriptors, use 0x10 (index 2, table 0, privilege 0). You need to set them right after you enter long mode.
And in your IDT, you need to use 0x8 (index 1, table 0, privilege 0) and not 0x8000 (index 4096, table 0, privilege 0) for the code selector.

I think I'll try adding a handler for each entry. The code still breaks whenever I turn on interrupts. Unless there is something I need the handler to do in order to make it work? Right now it calls an function in C that does nothing and then hangs with jmp $.

This makes a lot more sense now, thank you!

That's a progress Well, yes, I meant in general, however that's where it actually is on my distro.

Try bochsbios, that also contains the qemu BIOS at /usr/share/bochs/BIOS-qemu-latest. And about vgabios, that should be installed at /usr/share/vgabios/vgabios.bin (both packages should be already installed on your computer as bochs package depends on them. If not, just install them). Man, Ubuntu packages are insane

Cheers,
bzt

I got Bochs working, thank you so much! So it boots up, but just gives me a black screen and a terminal. Is there a command I need to use to boot into the OS?

Yes, same as with gdb and qemu -Ss: the machine is stopped right before any code is executed. This is to allow you to set up break points. Just continue execution with a "c" command.
Read this and this to get you started. Here's a list of available commands (not all of them, use "help" and "help info" commands at the debugger prompt to list them).

Some of the features that will make your life easier:
1. use xchg bx,bx instruction in your code if you want to invoke the debugger (exchanging a value with itself does nothing in other VMs) In contrast to int 3, this won't change the stack nor the VM's state in any way and works without a correct IDT too
2. use out 0e9h, al to print a character to the terminal (very handy and a single instruction is a lot simpler than sending a character to the serial port)
3. learn its debugger commands, for example "page" command will debug the page table walk for you, I've found that feature extremely useful (and no other debugger can do that)
4. using "info idt" will display the decoded IDT, also very useful
5. you can dump peripheral's registers too, like "info pic" or "info pit" (you'll see later how useful those are when you're debugging IRQs)

For example, you could do
and then at the bochs debugger prompt issue "s" command multiple times and you'll see step-by-step what's happening inside the CPU when you enable the interrupts flag, and what instructions lead to the triple fault.

Cheers,
bzt

Well, now your IDT has only one entry, so that's not going to work. You need at least 48 entries. You also still have a bad CS selector and the DPL is set to 1 instead of 0.

Thank you for pointing that out, I fixed the code so there is 48 IRQs now.
SKC said my CS selector should be good because it is set when I switch into long mode. Is there something else I am missing?
Also, I don't know what a DPL is, I apologize.

IDT descriptors are not IRQs. You should use the correct name, otherwise you might get confused!


Aren't you using 0x8 for your CS selector when you switch to long mode? You wrote 0x8000 in the IDT descriptor.


Descriptor Privilege Level. It's one of the fields in the IDT descriptor. It determines which privilege level is allowed to call each ISR using the INT instruction. For now, you should set the DPL to 0. You can always change it later if you decide less-privileged code needs to use the INT instruction.

To my understanding, the loop SKC wrote for me in an earlier reply should put 48 entries into the IDT. I think those are the descriptors. I also have 48 IRQs (I'm not sure how many of these I'm supposed to have).


I updated this after SKC pointed this out earlier.


Do I set that in the IDT.pointer section? How do I do that?

You're using the PICs, so you have 16 IRQs. You have 48 of something else. ISRs? IDT descriptors?


The DPL is bits 5 and 6 of this byte in the descriptor:

Change it to 10001110b to set the DPL to 0.

Well yes, but actually no. The loop sets the entries to the same handler. If you use it for the entire IDT, every interrupt/exception/IRQ will call the same code. Since you're in a very early stage, you can set the exception entries (0-31) to the same handler. However, as I said before, you will need to give each interrupt its own handler at some point. But for now, setting all the exceptions (only exceptions, not IRQs) to a dummy handler that just hangs is fine.

Oh, about your confusion with the naming, read this. I hope it helps