Обработка ошибок трансляции MMU в потоке команд - что происходит с MMU?

Этот вопрос не относится к какой-либо реализации ЦП, но приветствуются ответы, связанные с ЦП.

В настоящее время я использую ЦП с полной поддержкой MMU, и возникла простая проблема.

Итак, представьте ситуацию, когда происходит простой промах TLB, вызванный потоком инструкций (или кешем инструкций). Это вызовет промах TLB. Теперь, если PTE не найден, будет инициировано какое-то исключение, например «Ошибка перевода страницы». Пока никаких проблем.

Теперь, чтобы вызвать обработчик ошибок, поток инструкций (или кеш) должен получить код обработчика исключений. Для этого потребуется еще раз поиск соответствующей записи PTE в TLB и, в конечном итоге, еще один обход таблицы.

Представьте, что опять же запись PTE не найдена. Можно было бы ожидать вызова какого-то другого обработчика исключений.

Теперь, в этом последнем обработчике исключения, поскольку сам обработчик может быть не найден или не действителен, блокируется ли MMU до того, как обработчик будет выбран и выполнен (таким образом, обходя все, что делает MMU, включая отображение Phys-Virt), или есть другой метод (без смертельного исхода), чтобы справиться с этой ситуацией?

Алви


caching cpu tlb mmu
person Alvaro Lopes    schedule 29.08.2015    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Я не могу сказать это с уверенностью о реальной операционной системе, но, судя по небольшому опыту работы с небольшими ядрами, акцент всегда, похоже, делается на то, чтобы обработчик ошибок страницы сам по себе никогда не выгружался и всегда находился в определенном месте. это никогда не вызывает ошибки страницы. Это гарантирует, что ситуация, описанная в вашей проблеме, никогда не возникнет.

В общем, кажется логичным, что некоторая часть кода ядра ядра статически находится в физической памяти с известным отображением; но, учитывая, что вы все равно пытались написать полноценную ОС с виртуальной памятью, я думаю, вы бы знали об этом.

person Sudharshan Viswanathan    schedule 11.04.2016
comment
Мой вопрос на самом деле связан с аппаратным обеспечением, а не с программным обеспечением. Таким образом, если мы не можем должным образом обработать неисправность, единственный вариант - это полный сброс. Мне было интересно, можно ли для определенного сценария отключить MMU, чтобы этого не произошло. Например, может быть сопоставлен (жестко) с кодом прошивки. - person Alvaro Lopes; 12.04.2016

arrow_upward
1
arrow_downward

Я знаю два способа:

  1. MMU автоматически отключается при возникновении прерывания / исключения. Таким образом, обработчик ошибок (обработчик прерывания данных) должен быть размещен по известному физическому адресу, и о ложных ошибках MMU не может быть и речи. Это ответственность обработчика за повторное включение MMU перед возвратом из исключения или за использование самого обработчика. Такое поведение в реальной жизни - заноза в заднице ...
    Например, арка Microblaze делает именно это.

  2. MMU не отключается автоматически. Уловка состоит в том, чтобы иметь 2 набора таблиц TLB. TLB1 имеет таблицы сопоставления ядра, TLB0 предназначен для таблиц сопоставления пользовательских приложений. Соответственно, ядро ​​и пользовательские приложения должны иметь соответствующую связь, чтобы исключить перекрытие виртуальных адресов между собой.

    Когда пользовательское приложение делает дерьмо и вызывает ошибку MMU, возникает исключение. Обработчик прерывания / сбоя находится в области памяти ядра, поэтому доступ к коду обработчика будет осуществляться с помощью другого TLB. Вы должны быть чертовски уверены, что TLB ядра правильный :)

    Если обработчик исключений ядра сам генерирует исключение, то есть вероятность ложных данных и / или прерывания инструкции.
    Однако на практике процессоры "ARM-Ax", например, маскируют исключения / прерывания при их получении. Я думаю, что ложных исключений не бывает, хотя я никогда не проверял это на практике.

    И что ж, сторожевой таймер HW может оказать вам услугу ...

person user3124812    schedule 23.10.2018