OSDev.org

Long mode, switching to ring3
APIC on:
Bochs OK.
QEmu #GP at "iretq".

Where I was wrong?

1. Make sure rsp point to a valid stack for ring3 task
2. I don't know which assembler you use, but with NASM you need to explicitly specify REX.w prefix for sysret on BITS 64 section (64-bit mode).

summersong wrote:QEmu #GP at "iretq".

Where I was wrong?

What's the #GP error code? is it a selector or what?

1. stack valid
2. fasm, "iretq" (64) opposite "iret" (16/32); at ring 0 all OK

GPF error code -- I don't know

Stack at GPF:

00000020
0000073C
00000008
00000006
00200FD8 ; rsp?
00000000
00000000
00000FDD ; interrupt return offset?
0000002B ; code ring 3 selector + 3?
00000206 ; rflags
00201000 ; rsp = 201000
00000020 ; data selector?

GDT selectors:
00
08 code ring 0
10 data 0
18 code 3 ; \
20 data 3 ; > for SYSCALL
28 code 3 ; /
30 tss

You're entering long mode, yet you're guessing at the contents of the stack? Stop.

Go and grab the AMD or Intel manuals (the AMD ones are far better for long mode). Read them. Implement handlers for all the exceptions which dump the known CPU state prior to entering the exception handler.

You're rushing into things way too quickly. User mode is where you go when you have a solid kernel - when you have multiple threads of execution running in kernel mode, and when your exception handlers are able to reliably diagnose errors.

Build yourself solid foundations first.

EDIT: Derp; wrote "instructions" where I meant "exceptions"

Maybe I will rude, but I don't want to read again 3000 pages of technical documentation only just to fix 1 or 2 lines of code. If you think that someone can solve any problem just read the manuals - you're wrong. I have read them, but I do not remember word for word. I can solve the problem myself for a week or by the community for one hour (maybe). If you don't understand THIS...

SOLVED
It's wrong. Correct value is "001b0008h".

So the error was in a piece of code that you didn't show us and you found the answer by - I guess - reading the manual? I think there's a moral or two there. When people say "read the manual", it's not a cop out.

I was show only a new code.

I surfing internet, looking for similar problem. Only this forum have 4 or 5 topics with the same error.

"read the manual", "let's try to see how it works at Linux kernel", "f*** you" - this is not a help.

summersong wrote:"read the manual", "let's try to see how it works at Linux kernel", "f*** you" - this is not a help.

This is what you get for not asking proper questions and expecting others to solve your problems.

summersong wrote:"read the manual", "let's try to see how it works at Linux kernel", "f*** you" - this is not a help.

It's called the secret of actually putting in some effort. It achieved exactly what we wanted - you solved your own problem.

"lets try to see how it works at Linux kernel"

Here you go: http://www.amazon.com/Linux-Kernel-Deve ... 0672329468

summersong wrote:Maybe I will rude, but I don't want to read again 3000 pages of technical documentation only just to fix 1 or 2 lines of code.

If you think that people here want you to read through all 3000 pages when they say "read the manual", or to memorize them word-for-word, you don't know how to read manuals.

I have never read the entire Intel manual. I doubt many people have (In fact, it's a good bet that most or all of the people who put it together have never read the entire thing). Any given problem can usually be solved by reading just a few pages. Use the table of contents (if you have the big 3020 page PDF, the ToC's for the three volumes begin on pages 5, 377, and 1651) to find manual sections that might cover your problem. Use your PDF reader's search function to look for keywords related to your problem.

Manuals are not meant to be memorized word for word, or even usually to be read straight through. They are meant to be a reference where individual sections are looked up as needed.