Как в виртуальных процессорах устроена виртуальная память?

Question

[SergeySerge11]

Смотрю код qemu и других виртуальных машин(посматриваю), не могу понять зачем там реализуют разные модули, типа кеша, вроде в каком-то даже увидел конвеер исполнения команд, предсказатели переходов. И прочие. К примеру кеш, тлб, зачем он там нужен. если все как бы просиходит внутри машины? Зачем адрес куда-то в кеш записывать, если этот кеш 3 уровня, или регистр лежит с точки зрения внешней среды, там же где и ram и доступ должен быть одинаковым.

И второе. Ассоциативная память. Если там внутри делается таблица адресов, виртуальных адресов. То к примеру для адресного пространства 4гб, будет 2^32 это будет в 32 раза дольше. На бенчмаркинге доступ словарь как раз этот порядок показывает по сравнению с линейным массивом.
А для процессора абортивный словарь то же самое что и доступ к элементу. Если Можно ли так написать. За счет параллельности сравнивания битов. чего язык высоко уровня не может.
(Правда после этого всего, я начинаю понимать зачем там TLB буфера, хотя и сам поиск в TLB буфере на 1024 значений будет дольше).

Короче, в итоге для поиска адреса в супер жесткой виртуальной машине, будет до 32 операции сравнений по словарю, потом суммарно где же в кешах каждого уровня, куча прочих проверок .... .
Но виртуальные процессоры работают быстрее, чем я ожидаю. А ожидаю, я раз так в 100 минимум медленнее исполнение.(При этом они реализуют то что вроде как не нужно)
Единственное, что, может быть, что вся это рутина, jit-ется. И после одного исполнения упрощается в одну команду. (Но это предположение пока)

Comments

[Saboteur]

если взять QEMU, то кроме просто виртуальной машины, это еще и эмулятор конкретной архитектуры. Со всеми ее недостатками и плюсами и фичами, которые могут всплыть при нестандартном использовании

[Vindicar]

Был когда-то такой антиотладочный трюк в x86, когда инструкция перезаписывала следующую прямо за ней. При реальном исполнении следующая инструкция была бы уже в кэше, и перезапись не дала бы эффекта. А вот при отладке по шагам кэш был бы забит командами отладчика, и выполнилась бы уже перезаписанная инструкция.
Может, потому и приходится эмулировать архитектуру как можно полнее - мало ли сколько таких фокусов ещё...

[mayton2019]

Но виртуальные процессоры работают быстрее, чем я ожидаю. А ожидаю, я раз так в 100 минимум медленнее исполнение.

Знаешь есть старый анекдот про бабку которая "надвое" сказала. Или помру говорит или нет.

Вот мне всегда нравились такие вот рассуждения в плоскости расчетов. И всегда интересно откуда
беруться ожидания и цифры.

Это нужно быть очень синьорным системным инженером и наверное написать много эмуляторов
чтоб оперировать такого уровня прогнозом.

Как ты получил сто?

[jcmvbkbc]

Был когда-то такой антиотладочный трюк в x86, когда инструкция перезаписывала следующую прямо за ней. При реальном исполнении следующая инструкция была бы уже в кэше, и перезапись не дала бы эффекта.

Vindicar, я помню, что видел упоминания этой техники ещё в конце 90х, но сейчас не могу найти никаких конкретных данных о том, что происходит и на каких процессорах эта техника должна была работать. Процессоры вплоть до i486 вообще не имели архитектурно-видимого кеша, т.е. с их точки зрения кеш был неотличим от основной памяти.
Возможно эта техника была нацелена на внутренний пайплайн процессора, но опять же, пайплайн появился в i486, а уже в pentium pro появилось детектирование самомодифицирующегося кода сбрасывающее пайплайн при обнаружении записи в адреса из которых были прочитаны инструкции в настоящий момент находящиеся в пайплайне.
Короче, это, по всей видимости, очень ограниченный анти-отладочный трюк, работающий только на небольшом подмножестве x86, скорее всего только на i486 и pentium.

[Vindicar]

jcmvbkbc, вполне возможно! Просто мне кажется, это сравнительно простой пример того, как неочевидные особенности проца могут использоваться программой.

Answer 1

[jcmvbkbc]

зачем там реализуют разные модули, типа кеша, вроде в каком-то даже увидел конвеер исполнения команд, предсказатели переходов. И прочие. К примеру кеш, тлб, зачем он там нужен. если все как бы просиходит внутри машины?

Фронт-енды QEMU реализуют большую часть наблюдаемого поведения моделируемого ими процессора. Одно большое исключение -- это процессорный кеш: QEMU не моделирует поведение процессорного кеша. TLB во многих архитектурах доступен для прямого чтения/записи через команды процессора, нельзя сказать что он "внутри машины".

Зачем адрес куда-то в кеш записывать, если этот кеш 3 уровня, или регистр лежит с точки зрения внешней среды, там же где и ram и доступ должен быть одинаковым.

Покажи пример, обсудим конкретику?

Ассоциативная память. Если там внутри делается таблица адресов, виртуальных адресов. То к примеру для адресного пространства 4гб, будет 2^32 это будет в 32 раза дольше.

Это какие-то очень странные допущения и прикидки, а то, что они не учитывают такие параметры как размер TLB и его ассоциативность, показывает их безосновательность.

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

Нифига. В QEMU есть два уровня TLB -- один, моделируемый процессорным фронт-ендом, второй -- собственный TLB QEMU softmmu независимый от эмулируемого процессора, поиск по которому встроен в генерируемый JIT (который в QEMU называется TCG) код. Собственный TLB QEMU прямого отображения, т.е. поиск в этом TLB -- это всегда проверка одного элемента массива и загрузка одного отображения в случае успеха. Например вот так генерируется код для этого на хосте x86. В случае неудачи происходит вызов функции поиска в архитектурно-зависимом TLB. Вот так этот вызов генерируется, а вот пример его реализации во фронт-енде. Поскольку этот TLB моделирует конкретную архитектуру его ассоциативность может варьироваться в широких пределах, или он может вообще отсутствовать. В случае промаха или отсутствия TLB поиск может либо продолжаться дальше в таблицах страниц, например так, либо фронт-енд генерирует исключение доступа к памяти, например так.

В итоге операций при поиске трансляции для виртуального адреса может быть гораздо больше чем 32, которые ты предположил, в случае промахов, но цена промахов амортизируется тем, что чем более они дороги, тем более они редки. Но, конечно, задача намеренно обращающаяся к никогда не повторяющимся страницам памяти будет иметь очень низкую производительность при выполнении в QEMU softmmu.

Comments

[SergeySerge11]

понял пару разделов. Но вот все еще не могу понять. Как смотрю, что любой доступ к памяти, нужно в любом случае, обратится к tlb, в любом случае, это вызов функции с передачей параметров, и разбор адреса на n кусков, пара проверок.
То есть каждую инструкцию mov ptr, будет делиться адрес на части, проверятся, склеиваться. и только потом выполнятся. В добавок нужно еще политику кеширования поддерживать.
Что одну 1 ассемблерную превращает в 10-20 ассемблерных, даже при попадание.
То есть к каждой инструкции обращения в память, будет вызваться метод трансляции?
Или есть какие обходы, когда игнорится трансляция, как будто в реальном режиме.

Или вот чтение инструкции из EIP, каждое чтение по адресу, прочесть инструкцию PC+1 будет перед тем как исполнить, на фазе извлечения опять это делать? ведь сама инструкция так же в виртуальной памяти, хотя инструкция в 1/4096 случая в той же странице памяти, делать вот эти проверки, потом еще в самой инструкции, если она работает с памятью, еще. (Надеюсь я что-то не улавливаю, но потом пойму).

[jcmvbkbc]

любой доступ к памяти, нужно в любом случае, обратится к tlb

SergeySerge11, да.

в любом случае, это вызов функции с передачей параметров, и разбор адреса на n кусков, пара проверок.

Нет, не в любом. В лучшем случае (попадание в собственный TLB QEMU) это извлечение битового поля из виртуального адреса, загрузка значения (кешированный виртуальный адрес) из массива записей TLB по этому индексу и сравнение. Если сравнение успешное -- загрузка ещё одного значения (кешированный физический адрес). На это можно легко посмотреть, если запускать QEMU с ключами -d in_asm, op_opt,out_asm
Например такой вот код

movb    (%rbx), %al
        jmp     1f
1:

генерирует такой вот вывод:

IN:
0x001000ee:  8a 03                    movb     (%rbx), %al
0x001000f0:  eb 00                    jmp      0x1000f2

OP after optimization and liveness analysis:
 ld_i32 tmp11,env,$0xfffffffffffffff0     dead: 1  pref=0xffff
 movi_i32 tmp12,$0x0                      pref=0xffff
 brcond_i32 tmp11,tmp12,lt,$L0            dead: 0 1

 ---- 00000000001000ee 0000000000000000
 qemu_ld_i64 tmp0,rbx,ub,2                dead: 1  pref=0xf
 deposit_i64 rax,rax,tmp0,$0x0,$0x8       sync: 0  dead: 0 1 2  pref=0xffff

 ---- 00000000001000f0 0000000000000000
 goto_tb $0x0
 movi_i64 tmp3,$0x1000f2                  pref=0xffff
 st_i64 tmp3,env,$0x80                    dead: 0 1
 exit_tb $0x7f02d017d480
 set_label $L0
 exit_tb $0x7f02d017d483

OUT: [size=152]
  -- guest addr 0x00000000001000ee + tb prologue
0x7f02d017d540:  8b 5d f0                 movl     -0x10(%rbp), %ebx
0x7f02d017d543:  85 db                    testl    %ebx, %ebx
0x7f02d017d545:  0f 8c 58 00 00 00        jl       0x7f02d017d5a3
0x7f02d017d54b:  48 8b 5d 18              movq     0x18(%rbp), %rbx
0x7f02d017d54f:  48 8b fb                 movq     %rbx, %rdi
0x7f02d017d552:  48 c1 ef 07              shrq     $7, %rdi
0x7f02d017d556:  48 23 7d e0              andq     -0x20(%rbp), %rdi
0x7f02d017d55a:  48 03 7d e8              addq     -0x18(%rbp), %rdi
0x7f02d017d55e:  48 8b f3                 movq     %rbx, %rsi
0x7f02d017d561:  48 81 e6 00 f0 ff ff     andq     $0xfffffffffffff000, %rsi
0x7f02d017d568:  48 3b 37                 cmpq     (%rdi), %rsi
0x7f02d017d56b:  48 8b f3                 movq     %rbx, %rsi
0x7f02d017d56e:  0f 85 3b 00 00 00        jne      0x7f02d017d5af
0x7f02d017d574:  48 03 77 18              addq     0x18(%rdi), %rsi
0x7f02d017d578:  0f b6 1e                 movzbl   (%rsi), %ebx
0x7f02d017d57b:  48 8b 4d 00              movq     (%rbp), %rcx
0x7f02d017d57f:  88 d9                    movb     %bl, %cl
0x7f02d017d581:  48 89 4d 00              movq     %rcx, (%rbp)
  -- guest addr 0x00000000001000f0
0x7f02d017d585:  66 90                    nop
0x7f02d017d587:  e9 00 00 00 00           jmp      0x7f02d017d58c
0x7f02d017d58c:  48 c7 85 80 00 00 00 f2  movq     $0x1000f2, 0x80(%rbp)
0x7f02d017d594:  00 10 00
0x7f02d017d597:  48 8d 05 e2 fe ff ff     leaq     -0x11e(%rip), %rax
0x7f02d017d59e:  e9 75 2a e8 ff           jmp      0x7f02d0000018
0x7f02d017d5a3:  48 8d 05 d9 fe ff ff     leaq     -0x127(%rip), %rax
0x7f02d017d5aa:  e9 69 2a e8 ff           jmp      0x7f02d0000018
  -- tb slow paths + alignment
0x7f02d017d5af:  48 8b fd                 movq     %rbp, %rdi
0x7f02d017d5b2:  ba 02 00 00 00           movl     $2, %edx
0x7f02d017d5b7:  48 8d 0d bd ff ff ff     leaq     -0x43(%rip), %rcx
0x7f02d017d5be:  ff 15 0c 00 00 00        callq    *0xc(%rip)
0x7f02d017d5c4:  8b d8                    movl     %eax, %ebx
0x7f02d017d5c6:  e9 b0 ff ff ff           jmp      0x7f02d017d57b
0x7f02d017d5cb:  90                       nop
0x7f02d017d5cc:  90                       nop
0x7f02d017d5cd:  90                       nop
0x7f02d017d5ce:  90                       nop
0x7f02d017d5cf:  90                       nop
  data: [size=8]
0x7f02d017d5d0:  .quad  0x000055895af47e50

Если отсюда выкинуть служебный код остаётся следующее:

Загрузка регистра %rbx виртуального процессора в %rbx:
0x7f02d017d54b:  48 8b 5d 18              movq     0x18(%rbp), %rbx

Вычисление адреса записи в TLB QEMU для виртуального адреса в %rbx:
0x7f02d017d54f:  48 8b fb                 movq     %rbx, %rdi
0x7f02d017d552:  48 c1 ef 07              shrq     $7, %rdi
0x7f02d017d556:  48 23 7d e0              andq     -0x20(%rbp), %rdi
0x7f02d017d55a:  48 03 7d e8              addq     -0x18(%rbp), %rdi

Выделение адреса страницы из виртуального адреса в %rbx:
0x7f02d017d55e:  48 8b f3                 movq     %rbx, %rsi
0x7f02d017d561:  48 81 e6 00 f0 ff ff     andq     $0xfffffffffffff000, %rsi

Сравнение адреса страницы и виртуального адреса адреса в TLB
0x7f02d017d568:  48 3b 37                 cmpq     (%rdi), %rsi

Если не сходится -- перейти к вызову обработчика эмуляции TLB процессора:
0x7f02d017d56b:  48 8b f3                 movq     %rbx, %rsi
0x7f02d017d56e:  0f 85 3b 00 00 00        jne      0x7f02d017d5af

Иначе (сошлось) -- вычислить "физический" адрес по виртуальному:
0x7f02d017d574:  48 03 77 18              addq     0x18(%rdi), %rsi

Загрузить байт из памяти:
0x7f02d017d578:  0f b6 1e                 movzbl   (%rsi), %ebx

Записать загруженный байт в регистр виртуального процессора %al:
0x7f02d017d57b:  48 8b 4d 00              movq     (%rbp), %rcx
0x7f02d017d57f:  88 d9                    movb     %bl, %cl
0x7f02d017d581:  48 89 4d 00              movq     %rcx, (%rbp)

Т.е. 11 команд на преобразование виртуального адреса в "физический" в случае успеха.

Или есть какие обходы, когда игнорится трансляция, как будто в реальном режиме.

Нет.

Или вот чтение инструкции из EIP, каждое чтение по адресу, прочесть инструкцию PC+1 будет перед тем как исполнить, на фазе извлечения опять это делать?

Да, будет, но обычно не на каждую инструкцию. QEMU обычно транслирует инструкции не по одной а базовыми блоками -- все инструкции подряд, но не больше некоторого максимума, или пока не встретится инструкция вызывающая переход, генерирующая исключение или встретится граница страницы виртуальной памяти. И один раз оттранслировав блок инструкций она сохраняет его в кеше, до тех пор, пока кто-то не перезапишет физическую память откуда они были прочитаны или блок не будет вытеснен из кеша естественным путём.