Как 64-разрядное ядро Linux управляет таблицами страниц для 32-разрядного приложения в режиме совместимости?
Под Linux полная команда:
/opt/VRTS/bin/fstyp -v /dev/vx/dsk/group11/vol11
Итак, прежде всего, невозможно просто так запустить 32-битный исполняемый файл в 64-битной системе. Таким образом, вам не нужно переводить 32-битный адрес в 64-битный адрес или что-то в этом роде.
Во-вторых, 32-битная (без PAE )просто не позволяет отображать память выше границы 4 ГБ.
Я много думал о проблеме и, прочитав раздел несколько раз, разобрался. Возможно, вы видели аналогичный вопрос в StackOverflow:Уровни разбиения памяти ядра Linux
Но я пытаюсь объяснить, как я это понял. Я пытаюсь объяснить, как четырехуровневая подкачка работает в 32-битной системе.
Первое предложение является существенным
[...] eliminates the Page Upper Directory and the Page Middle Directory fields by saying that they contain zero bits.
Это не означает, что ядро устанавливает эти поля равными нулю, но оно говорит, что они равны нулю, не выражая этого где-либо. Таким образом, у вас есть обычное 32-битное разделение адресов для двухуровневого пейджинга.
Это означает, что вы используете 10 старших битов виртуального адреса для PML4 (Linux :PGD ).
PML4 (Linux :PGD )указывает на PDPT (Linux :PUD ), который имеет только одну запись. Поскольку ядро говорит, что индекс/смещение равно нулю, берется только эта запись.
Единственная запись PDPT (Linux :PUD )указывает на PD (Linux :PMD ), который снова имеет только одну запись. И снова ядро говорит, что индекс/смещение равно нулю, поэтому берется только эта запись.
И, наконец, единственная запись PD (Linux :PMD )указывает на PT, где промежуточные 10 бит виртуального адреса используются в качестве индекса для поиска нужной страницы.
Вкратце:
[1024 *] PML4 (Linux: PGD) -> 1 * PDPT (Linux: PUD) -> 1 * PD (Linux: PMD) -> 1024 * PT