company_banner

Адреса памяти: физические, виртуальные, логические, линейные, эффективные, гостевые

  • Tutorial
Мне периодически приходится объяснять разным людям некоторые аспекты архитектуры Intel® IA-32, в том числе замысловатость системы адресации данных в памяти, которая, похоже, реализовала почти все когда-то придуманные идеи. Я решил оформить развёрнутый ответ в этой статье. Надеюсь, что он будет полезен ещё кому-нибудь.
При исполнении машинных инструкций считываются и записываются данные, которые могут находиться в нескольких местах: в регистрах самого процессора, в виде констант, закодированных в инструкции, а также в оперативной памяти. Если данные находятся в памяти, то их положение определяется некоторым числом — адресом. По ряду причин, которые, я надеюсь, станут понятными в процессе чтения этой статьи, исходный адрес, закодированный в инструкции, проходит через несколько преобразований.



На рисунке — сегментация и страничное преобразование адреса, как они выглядели 27 лет назад. Иллюстрация из Intel 80386 Programmers's Reference Manual 1986 года. Забавно, что в описании рисунка есть аж две опечатки: «80306 Addressing Machanism». В наше время адрес подвергается более сложным преобразованиям, а иллюстрации больше не делают в псевдографике.

Начнём немного с конца — с цели всей цепочки преобразований.

Физический адрес


Конечный результат всех преобразований других типов адресов, перечисленных далее в этой статье — физический адрес. На нём кончается работа внутри центрального процессора по преобразованию адресов.
Конечный результат?!
На самом деле, легко понять, что это ещё не конец. В платформе, которая должна обработать запрос данных от процессора, может быть несколько чипов DRAM, имеющих собственную структуру разбиения на блоки, а также различные периферийные устройства, отображённые на общее пространство физической памяти. Дальнейший путь транзакции с некоторым физическим адресом будет зависеть от конфигурации нескольких декодеров, находящихся на её пути внутри устройств платформы.


Эффективный адрес


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

Например, для инструкции (ассемблер в AT&T-нотации)

addl %eax, 0x11(%ebp, %edx, 8)


эффективный адрес операнда-назначения будет вычислен по формуле:

eff_addr = EBP + EDX * 8 + 0x11


Логический адрес


Без знания номера и параметров сегмента, в котором указан эффективный адрес, последний бесполезен. Сам сегмент выбирается ещё одним числом, именуемым селектором. Пара чисел, записываемая как selector:offset, получила имя логический адрес. Так как активные селекторы хранятся в группе специальных регистров, чаще всего вместо первого числа в паре записывается имя регистра, например, ds:0x11223344.

Здесь обычно у тех, кто столкнулся с этими понятиями впервые, голова начинает идти кругом. Несколько упростить (или усложнить) ситуацию помогает тот факт, что почти всегда выбор селектора (и связанного с ним сегмента) делается исходя из «смысла» доступа. По умолчанию, если в кодировке машинной инструкции не сказано иного, для получения адресов кода используются логические адреса с селектором CS, для данных — с DS, для стека — с SS.

Линейный адрес


Эффективный адрес — это смещение от начала сегмента — его базы. Если сложить базу и эффективный адрес, то получим число, называемое линейным адресом:

lin_addr = segment.base + eff_addr


Преобразование логический → линейный не всегда может быть успешным, так как при его исполнении проверяется несколько условий на свойства сегмента, записанных в полях его дескриптора. Например, проверяется выход за границы сегмента и права доступа.
Реальный режим
Описанное выше верно при включенной сегментации. В 16-битном реальном режиме смысл селекторов другой, они хранят только базу, а преобразование не осуществляет сегментных проверок. Фактически, обозначения CS, DS, FS, GS, ES, SS имеют совершенно разный смысл в этих двух режимах, что добавляет путаницы.

Сегментация была модной на некотором этапе развития вычислительной техники. В настоящее она почти всюду была заменена другими механизмами, и используется только для специфических задач. Так, в режиме IA-32e (64-битном) только два сегмента могут иметь ненулевую базу. Для остальных четырёх в этом режиме всегда линейный адрес == эффективный.

Что такое виртуальный адрес?

В литературе и в документации других архитектур встречается ещё один термин — виртуальный адрес. Он не используется в документации Intel на IA-32, однако встречается, например, в описании Intel® Itanium, в котором сегментация не используется. Можно смело считать, что для IA-32 виртуальный == линейный.
В советской литературе по вычислительной технике этот вид адресов также именовался математическим.

Страничное преобразование


Следующее после сегментации преобразование адресов: линейный → физический — имеет множество вариаций в своём алгоритме, в зависимости от того, в каком режиме (32-битном, PAE или 64-битном) находится процессор.
Что влияет на paging
Примечательно, сколько различных бит из разных системных регистров процессора влияют на процесс страничного преобразования в настоящее время. Я просмотрел свежую сентябрьскую редакцию Intel SDM [1], и вот полный список: CR0.WP, CR0.PG, CR4.PSE, CR4.PAE, CR4.PGE, CR4.PCIDE, CR4.SMEP, CR4.SMAP, IA32_EFER.LME, IA32_EFER.NXE, EFLAGS.AC.

Однако общая идея всегда одна и та же: линейный адрес разбивается на несколько частей, каждая из которых служит индексом в одной из системных таблиц, хранящихся в памяти. Записи в таблицах — это адреса начала таблицы следующего уровня или, для последнего уровня — искомая информация о физическом адресе страницы в памяти и её свойствах. Самые младшие биты не преобразуются, а используются для адресации внутри найденной страницы. Например, для режима PAE с размером страниц 4 кбайт преобразование выглядит так:



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

Гостевой физический


До введения возможностей аппаратной виртуализации в процессорах Intel страничное преобразование было последним в цепочке. Когда же на одной системе работают несколько виртуальных машин, то физические адреса, получаемые в каждой из них, приходится транслировать ещё один раз. Это можно делать программным образом, или же аппаратно, если процессор поддерживает функциональность EPT (англ. Extended Page Table). Адрес, раньше называвшийся физическим, был переименован в гостевой физический для того, чтобы отличать его от настоящего физического. Они связаны с помощью EPT-преобразования. Алгоритм последнего схож с ранее описанным страничным преобразованием: набор связанных таблиц с общим корнем, последний уровень которых определяет, существует ли физическая страница для указанной гостевой физической.

Полная картина


Я попытался собрать все преобразования адреса в одну иллюстрацию. В ней преобразования обозначены стрелками, типы адресов обведены в рамки.



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

Заключение


Эволюция, что в природе, что в технике — странная вещь. Она порождает неожиданные структуры, необъяснимые с точки зрения рационального проектирования. Её творения полны атавизмов, правила их поведения иногда почти полностью состоят из исключений. Для того, чтобы понять работу такой системы, часто требуется прокрутить её эволюцию с самого начала, и под нагромождениями всех слоёв найти истину в виде принципа: «ничего не выбрасывать». Я склонен считать архитектуру IA-32 замечательным примером эволюционного развития.
P.S. Всё как у всех
Вскоре после завершения написания этой статьи я натолкнулся на презентацию об архитектуре IBM System z, которая примечательна в том числе своей долгой и интересной историей поддержки виртуализации. В этом документе нашлось перечисление всех типов адресов памяти, используемых в System z:
  1. Virtual: Translated by dynamic address translation (DAT) to real addresses
  2. Real: Translated to absolute addresses using the prefix register
  3. Absolute: After applying the prefix register
  4. Logical: The address seen by the program (this can either be a virtual or a real address)
  5. Physical: translated to absolute addresses by the Config Array


Как можно заметить, их тоже пять.


Спасибо за внимание!

Литература


  1. Intel Corporation. Intel® 64 and IA-32 Architectures Software Developer’s Manual. Volumes 1–3, 2014. www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html
Intel
176.24
Company
Share post

Comments 11

    0
    это вводная статья?
      0
      Я планировал эту заметку как самодостаточную и раскрывающую ответ ровно на тот вопрос, который часто задаётся. Однако, если есть какие-то смежные темы, оставшиеся непонятными, то я могу попробовать описать их или тут, в обсуждении, или же в более развёрнутом виде, если потребуется.
      0
      можете описать механизм rip-адресации в ia64?
        0
        Сразу уточняющий вопрос — под ia64 подразумевается Intel Itanium? Если да, то в нём формата инструкции для IP-relative адресации не предусмотрено. Для написания position independent code на этой архитектуре можно просто загрузить значение ip в любой регистр общего назначения, а затем использовать его с нужным смещением.

        Или всё-таки имелась в виду архитектура Intel 64?
          0
          intel 64
            +6
            Тогда сперва, я думаю, стоит объяснить, зачем RIP-relative адресация вообще нужна. А нужна она для эффективной поддержки т.н. position-independent code (PIC), т.е. машинного кода, работоспособность которого не зависит от его положения в памяти.

            Чаще всего необходимость в PIC возникает для разделяемых библиотек. При раздельной компиляции каждой библиотеки необходимо где-то разместить данные, с которыми она работает; использующий их код будет использовать константы-смещения для их адресации. При загрузке нескольких независимых библиотек может произойти конфликт: две или более библиотек будут хотеть разместить данные по одним и тем же адресам.

            Для решения этой проблемы неободимо ввести уровень косвенности: «плавающую» адресацию данных. Можно при загрузке каждой библиотеки высчитывать адреса данных заново и переписывать их прямо в коде. Можно выбрать и использовать некоторый регистр, значение которого будет определять начало блока данных для конкретной библиотеки, и изменять только его значение при переходах между ними.

            Наверное, самым изящным решением является выбор указателя текущей инструкции (RIP, EIP, IP, PC, IC…) в качестве такого регистра. На этапе компиляции известно «расстояние» между инструкцией, использующей некоторую переменную, и положением самой переменной в памяти. Самое важное — эта величина не меняется, где бы в памяти мы не разместили библиотеку в будущем. Поэтому смещение относительно счётчика инструкций можно как константу зашить прямо в машинный код инструкции. При условии, что кодировка набора команд это позволяет.

            Изначально Intel IA-32 не имела такой тип адресации. Смещения можно было указывать только относительно регистров общего назначения. Кроме того, не было возможности загрузить значение EIP прямо в регистр — это можно было сделать только через операции над памятью, использующие стек, и вызов подпроцедуры, помещающей EIP на стек.

            call read_eip // eip -> eax
            
            <...>
            
            read_eip: movl (%esp), %eax
            ret
            

            (Кстати, это тот самый случай, когда попытка inline-оптимизации рушит всё веселье!)

            Конечно, это всё жутко неэффективно и коряво. Поэтому в компиляторах для 32-битного режима IA-32 по умолчанию режим PIC выключен.

            С приходом Intel 64 в набор инструкций был добавлен новый способ адресации (вместо неиспользуемого в 64-битном режиме 32-битного смещения при использовании байта SIB). Для него идущая после байта ModRM 32-битная константа трактуется как смещение со знаком относительно RIP.

            Возможно, следующий пример поможет проиллюстрировать сказанное выше. В нём я ассемблирую программу из единственной инструкции, использующей RIP-relative адресацию операнда в памяти, и вывожу результат дизассемблирования.

            user@host:~$ cat 1.s 
            movq %rax, 0xaabb(%rip)
            
            user@host:~$ as 1.s 
            user@host:~$ objdump -d a.out 
            
            a.out:     file format elf64-x86-64
            
            
            Disassembly of section .text:
            
            0000000000000000 <.text>:
               0:   48 89 05 bb aa 00 00    mov    %rax,0xaabb(%rip)        # 0xaac2
            


            Здесь в результирующем машинном коде 0x48 — это REX-префикс, 0x89-часть опкода, а 0x05 — байт ModRM, кодирующий, в том числе, тот факт, что используется RIP-relative адресация, и что последующие четыре байта определяют смещение (0x0000aabb) относительно адреса инструкции, следующей за текущей.

            Отмечу следующие интересные моменты.

            0. Практически все архитектуры поддерживают адресацию относительно текущей команды для инструкций переходов, т.е. jmp, branch, call. Не следует путать их с rip-relative адресацией — в них не происходит обращений к памяти.
            1. Поддержка адресации относительно указателя текущей инструкции существует в других архитектурах, например, в ARM, VAX, 6809.
            2. В английской Википедии есть исчерпывающая статья по типам адресации: en.wikipedia.org/wiki/Addressing_mode#PC-relative_2.

              0
              Гриша, про PIC (и ABI?) давай лучше отдельный пост напиши?
                +1
                О, привет ☺
                Если будут силы и время — попробую. Про ABI так можно целый цикл заметок сделать — очень уж интересный вопрос.
                0
                Спасибо) Даже больше, чем было нужно.
                  +1
                  Добавлю как разработчик UEFI — аппаратной поддержки PIC для x86 очень не хватает. Для x64 такой код может быть сгенерирован компилятором, а для x86 его приходится либо писать на ассемблере, когда нельзя сделать его исполняемым на месте, либо вычислять реальный базовый адрес и патчить relocation table.
            +2
            Тем не менее, ИМХО, опять же, в псевдографике выглядит понятнее =)

            Only users with full accounts can post comments. Log in, please.