Обработка ошибок перевода MMU в потоке команд - что происходит с MMU?
Этот вопрос не относится к какой-либо реализации ЦП, но приветствуются ответы на него.
В настоящее время я использую процессор с полной поддержкой MMU, и возникла простая проблема.
Итак, представьте себе ситуацию, когда происходит простой промах TLB, вызванный потоком инструкций (или кешем инструкций). Это вызвало бы промах TLB. Теперь, если PTE не найден, сработает какое-то исключение, например, "Ошибка перевода страницы". Пока проблем нет вообще.
Теперь, чтобы вызвать обработчик ошибок, поток инструкций (или кэш) должен получить код обработчика исключений. Для этого ему нужно будет снова найти соответствующую запись PTE в TLB и, в конечном итоге, еще один обход таблицы.
Представьте, что снова запись PTE не найдена. Можно было бы ожидать вызова другого обработчика исключений.
Теперь, в этом последнем обработчике исключений, так как сам обработчик может не быть найден или быть действительным, отключается ли MMU до того, как обработчик извлекается и исполняется (таким образом, обходя все MMU, включая отображение Phys-Virt), или есть другой метод? (не смертельно) иметь дело с этой ситуацией?
Alvie
2 ответа
Есть два способа, о которых я знаю:
MMU отключается автоматически при возникновении прерывания / исключения. Таким образом, обработчик сбоев (обработчик сброса данных) должен быть размещен по известному физическому адресу, а ложные сбои MMU исключены. Это ответственность обработчика за включение MMU перед возвратом из исключения или за использование самого обработчика. Такое поведение, в реальной жизни, довольно больно в задницу...
Например, арка Microblaze делает именно это.MMU не отключается автоматически. Хитрость заключается в том, чтобы иметь 2 набора таблиц TLB. TLB1 имеет таблицы отображения ядра, TLB0 предназначен для таблиц отображения пользовательских приложений. Соответственно, приложения ядра и пользователя должны иметь соответствующие связи, чтобы исключить перекрытие виртуальных адресов между собой.
Когда пользовательское приложение делает sh** и вызывает ошибку MMU, возникает исключение. Обработчик сброса / сбоя находится в области памяти ядра, поэтому к коду обработчика будет обращаться с другим TLB. Вы должны быть чертовски уверены, что ядро TLB правильно:)
Если обработчик исключений ядра сам генерирует исключение, то существует вероятность ложных данных и / или инструкций по прерыванию.
На практике, однако, процессоры "ARM-Axe", например, маскируют исключения / прерывания, когда они принимаются. Я думаю, что ложных исключений не бывает, хотя я никогда не проверял это на практике.
И HW Watchdog может оказать вам услугу...
Я не могу с уверенностью сказать это о реальной операционной системе, но из небольшого опыта работы с маленькими ядрами акцент всегда делается на обеспечении того, чтобы обработчик ошибок страницы сам по себе никогда не был выгружен и всегда находился в определенном месте. это никогда не вызывает ошибку страницы. Это гарантирует, что ситуация, описанная в вашей проблеме, никогда не возникнет.
В целом, кажется, имеет смысл, что некоторая часть кода ядра ядра статически располагается в физической памяти с известным отображением; но, учитывая, что вы все равно пытались написать полноценную ОС с поддержкой виртуальной памяти, я думаю, вы бы знали об этом.