что будет при iret из ring0 в ring3 если страница куда идет возврат выгружена из памяти?

Если я правельно помню, то зависет от ОС.
Проц тока сгенерирует исключение... а дальше ОС , например может загрузить страницу в память и передать туда управление, или выдать ошибку.

Кроме того, способ передачи управления также может быть разным.

Например, если установлен флаг Nested Task, то iret будет переключать задачу по backlink в TSS.

дело в том что я ось и пишу. потому стало интересно что будет при вызове ядром функции callback'а если его код не подгружен в память.

Использовать iret для callback?
"Оригинально-с" (с) проучик Ржевский. ;)

Как известно, переход с одного уровня на другой - дело не простое. Для этого у процессора есть несколько механизмов. Какой именно будет использоваться?

И почему для совершения действия выбрана именно команда iret?

потому что в книжке зубкова русским по белому написано - на третий уровень управление передается только по iret и не хочу я стек ядра трогать! пусть останется как есть на момент вызова.

В доке INTEL написанно(в рамках моего знания английского :)) что и RET и IRET могут менять приоретет, тока ret извлекает из стека dw а IRET ещё и значения сегменто(вроде).

флаги она извлекает!!

Narkomanius, ладно флаги, не суть важно.

дык все таки. call в немапаную память себя как ведет например? он выполнится, после чего последует #PF, или
#PF произойдет первее?

Narkomanius

Вот смотри, первоначальный вопрос был типа: "я хочу написать ось, и хочу чтобы там были callback с помощью iret, как это сделать?". Трудно ответить что либо, кроме "так в чём проблема?".

В больших мануалах описание команды iret содержит одну страницу текста и ПЯТЬ страниц псевдокода формального описания её действия в самых различных ситуациях. В защищённом режиме эта команда может выполнять пять различных действий в зависимости от ситуации:
-- возврат из V86
-- возврат в V86
-- возврат в тот же уровень привилегий
-- возврат в другой уровень привелегий
-- переключение задачи из Nested Task.
Следовало бы уточнить какая именно ситуация подразумевается. ;)

Теперь вдруг выясняется, что вопрос в том, произойдёт #PF "до или после". Если собственно возврат произошёл успешно, то конечно же #PF произойдёт после него. Я сильно удивлюсь если кто-нибудь скажет (и докажет) обратное. Однако, ключевое слово здесь "возврат произошёл успешно". Если исключение возникает при попытке обращения к стеку для того, чтобы достать из него адрес возврата, то исключение, очевидно, произойдёт до того как совершится возврат...

Моя любимая глава в больших мануалах (и как раз по теме) это "Interrupt and Exception handling" из третьего тома. Каждый раз как я читаю её, всегда нахожу что-то новое (и говорю "ни фига себе", как мужик из анекдота, который читал орфографический словарь). Рекомендую.

Например, знаешь ли ты, что все прерывания и исключения делятся на три категории: benign, contributory, page fault?

Кстати, когда-то тому назад у меня был вопрос на похожую тему вот здесь:
http://www.wasm.ru/forum/index.php?action=vthread&forum=7&topic=5365
и мне тоже никто не ответил. :(
Поэтому мне кажется, что этот форум не очень подходит для оживлённых творческих дискуссий о тонкостях системной архитектуры IA-32. Поэтому остаётся только один путь - самостоятельные эксперименты. С помощью экспериментов затруднительно сделать только две вещи:
-- посмотреть как там в процессоре инструкции спариваются ;)
-- расколоть пропатчивание микрокода.
Всё остальное - решаемо. Нужно только чётко понимать цель и смысл своих действий...