Линус Торвальдс о том, как AMD и Intel меняют способ обработки прерываний процессора

И AMD, и Intel незаметно для себя решили, что пора, наконец, очистить некоторые действительно древние и необычные варианты дизайна процессоров, которые восходят к архитектуре 80286 начала 1980-х годов. Они идут разными путями, и Линус Торвальдс, основатель Linux, недавно поделился своими мыслями о выборе дизайна их процессоров.  

AMD была первой, кто представил свои предлагаемые изменения в феврале 2021 года: расширения доступа AMD Supervisor Entry Extensions. Intel последовала в марте с гибким дизайном возврата и доставки событий (FRED). Интерес Торвальда вызвал тот факт, что кто-то на форуме по глубоким технологиям Real World Technologies представил тему с пометкой: «x86 - зачем объединяться, если можно фрагментировать?»

Однако Торвальдс так не считает. Он написал:

Честно говоря, выглядит неплохо.

Версия AMD - это, по сути, «Исправить известные ошибки в определении обработки исключений».

Версия для Intel в основном такова: «Да, обработка исключений в защищенном режиме 80286 была плохой, затем 386 сделала ее странной с 32-битными расширениями, а затем syscall / sysenter сделали все еще хуже, а затем расширения x86-64 принесли еще больше проблем. Так что давайте добавим немного режима, в котором уходит вся эта чушь".

Напротив, AMD - это, по сути, минимальные усилия по исправлению реальных фундаментальных проблем со всем этим унаследованным дерьмом, которое неприятно обходить и которое вызвало проблемы.

Итак, что это за проблемы? Они скрыты таблицей дескрипторов прерываний (IDT) архитектуры x86. Это структура данных, которая реализует таблицу векторов прерываний. К сожалению, это связано с многочисленными проблемами, связанными с исключением. 

К ним, по словам Торвальдса, относятся:

• Сам IDT представляет собой ужасно неприятный формат, и вам не придется анализировать память странными способами для обработки исключений. Это было принципиально плохо с начала 80286, стало немного сложнее разбираться для 32-битных, и, возможно, стало намного хуже в x86-64.
• RSP регистр общего назначения не восстанавливается должным образом в режиме возврата в пользователя.
• Отложенные ловушки отладки в режиме супервизора.
• Несколько проблем с вложением исключений: немаскируемые прерывания (NMI), машинные проверки и, по крайней мере, обработка теней STI).
• Различные проблемы атомарности с gsbase (подкачки) и переключением указателя стека
• Несколько разных макетов стека исключений и буквально сотни разных точек входа для исключений, прерываний и системных вызовов (и это даже не считая шлюзов вызовов, которые никто не должен использовать в первую очередь).

Торвальдс заключил: «Но я подозреваю, что кое-что забыл». Короче говоря, это беспорядок, и с некоторого времени он становится все сложнее.