Могут ли процессоры Intel задерживать недействительность TLB?

Question

Это относится к Руководству разработчика программного обеспечения InteI (номер заказа: 325384-039US, май 2011 г.), раздел 4.10.4.4 «Отложенная недействительность», описывает потенциальную задержку недействительности записей TLB, которая может привести к непредсказуемым результатам при доступе к памяти, чья подкачка-структура была изменена.

В руководстве говорится ... " Необходимые аннулирования могут быть отложены при некоторых обстоятельствах. Разработчики программного обеспечения должны понимать, что между модификацией записи структуры пейджинга иПри выполнении инструкции по аннулированию, рекомендованной в Разделе 4.10.4.2, процессор может использовать переводы, основанные либо на старом значении, либо на новом значении записи в структуре пейджинга. Следующие элементы описывают некоторые из потенциальных последствий отложенной аннулирования: Еслизапись в структуре пейджинга модифицируется для изменения флага R / W с 0 на 1, доступ для записи в линейные адреса, перевод которых управляется этой записью, может вызывать или не вызывать исключение ошибки страницы."

Давайте предположим простой случай, когда запись структуры страницы модифицируется (флаг r / w переключается с 0 на 1) для линейного адреса, и после этого вызывается соответствующая инструкция аннулирования TBLнемедленно.Мой вопрос - как следствие отсроченной аннулирования TLB s, возможно, что даже после вызова аннулирования TLB доступ на запись к линейному адресу, о котором идет речь , не является ошибкой (страницаошибка)?

Или «отложенная аннулирование» может привести к непредсказуемым результатам только в том случае, если не была выдана команда «аннулировать» для линейного адреса, структура страницы которого была изменена?

Answer 1

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

Все это происходит прозрачно с процессором. Ваша программа (или ОС) не должна быть в состоянии определить разницу между этим поведением и тем, что TLB фактически становится недействительным из-за аннулирования TLB, кроме как через:

• A) Сроки - то есть TLB оптимистично не кэширует быстрее (вот почему они это делают)
• B) Есть крайние случаи, когда это поведение несколько не определено. Если вы измените кодовую страницу, на которой вы сидите, или коснитесь памяти, которую вы только что изменили, старое значение TLB все еще может быть (даже при изменении CR3).

Решением этого является либо:

• 1) принудительно обновить TLB с помощью инструкции invlpg. Это очищает запись TLB, вызывая чтение TLB при следующем касании страницы.
• 2) отключить и снова включить пейджинг через регистр CR0.
• 3) пометить все страницы как не кэшируемые с помощью бита отключения кэша в CR0 или на всех страницах TLB (записи TLB, помеченные как uncachable, автоматически удаляются после использования).
• 4) Изменить режим кодового сегмента.

Обратите внимание, что это действительно неопределенное поведение. Переход на SMM может сделать недействительным TLB или нет, оставляя это открытым для состояния гонки. Не зависит от этого поведения.