Разница между подтипами исключения прерывания данных ARMv8 "Не в таблице перевода" и "Ошибка таблицы перевода на уровне"? - PullRequest
1 голос
/ 22 сентября 2019

Я получил виртуальную память, работающую на ARMv8 после создания таблиц страниц.Как ни странно, большинство моих переводов работают (с идентификацией), кроме Flash, который находится по нулевому физическому адресу.Я использую одну функцию, которая редактирует таблицы страниц, поэтому тот факт, что некоторые работают и некоторые не странны для меня.В частности, у меня есть только несколько сопоставленных диапазонов:

Flash       [0x00000000, len = 0x08000000]
UART        [0x09000000, len = 0x1000    ]
RAM         [0x40000000, len = 0x0fe00000]
Secure RAM  [0x4fe00000, len = 0x00200000]

И снова, они все работают за исключением Flash.Моя функция отображения также работает для неидентификационных карт.В этом диапазоне Flash есть что-то странное.

У меня есть обработчик исключений, который я использую для разбора проблемы.Я обнаружил два интересных случая при обнаружении Data Abort исключений.Я обнаружил два подтипа прерывания данных в зависимости от типа доступной памяти:

    - [1] Flash address range (e.g. 0x00000000)
            - ESR.ISS = 0x10 (ISS.DFSC = 0x10)
                - Synchronous External abort, not on translation table walk 

    - [2] An expected unmapped address (e.g. 0x50000000)
            - ESR.ISS = 0x06 (ISS.DFSC = 0x06)
                - Synchronous External abort, on translation table walk, level 2

При попытке обработать исключение для доступа к адресу, я не ожидаю, что будет вТаблица Я получаю [2] (ошибка на уровне 2, потому что некоторые близлежащие адреса были сопоставлены).

Когда я пытаюсь обработать исключение для доступа к Flash, которое я ожидаю вЯ получаю таблицу [1] (не в таблице ходить).

Итак, я запутался в том, что представляют собой эти два случая.В чем разница между [1] и [2]?Кажется, они представляют одно и то же.Представляет ли [1] случай, когда перевод потерпел неудачу до попытки?Есть определенные ошибки уровня 0, которые я бы ожидал устранить, если бы это было так.Я ожидал ошибки «Нет в таблице» для адреса, которого я не ожидал найти в таблице, но вместо этого получил другой.

1 Ответ

0 голосов
/ 23 сентября 2019

Как выяснилось, проблема, с которой я столкнулся, была связана с тем, что Flash отображался как Безопасное -только устройство, поэтому только безопасный доступ будет осуществляться через MMU (т.е. NSTable = 0 для записей таблицы).и NS = 0 для записей блока).

После осознания этого и с помощью @artlessnoise о «внешних прерываниях» в комментариях я пришел к следующему различию между двумя подтипами сброса данных:

"Not on translation table walk"

На мой взгляд, это не означает, что «Исключение произошло, потому что запрошенный адрес памяти не был найден« при просмотре таблицы перевода »».Скорее, это означает, что исключение произошло, когда «не на блуждании по таблице перевода» (т.е. до или после операции).В этом случае Flash PA был отображен в таблицах, но мои обращения были незащищенными, поэтому устройство не отвечало (MMU не направлял их через устройство).Это отсутствие реакции вызвало внешний прерывание.Таким образом, ARM может более кратко определить это исключение как, например:

"Not on translation table walk" -> "Not as a result of translation table walk"

Другой подтип:

"On translation table walk, level 2"

Это то, что следует ожидать во время page fault,Другими словами, была сделана попытка чтения памяти, которая не имеет сопоставления VA-> PA в таблицах перевода.Наблюдаемый уровень отражает, как далеко MMU проходит таблицы перед остановкой.


Обратите внимание, что я удалил часть определений «Синхронный внешний прерывание».Оба считаются внешними прерываниями, потому что оба возникают в результате операций вне ЦП при попытке чтения памяти или непосредственно из MMU.

...