IA-32 определяет различные случаи, когда ЦП может аннулировать весь TLB. Начиная с расширений ASID, выпущенных AMD в процессорах Opteron Rev-F (Barcelona?), Есть случаи, когда недействительны только записи TLB определенного ASID.Когда ASID в таблицах страниц AMD больше недействителен?
Вопрос в том, действительно ли ASID перестает быть действительным? Должен ли Hypervisor проверять, что ASID действителен до его использования?
Я думаю ответ «не напрямую» - глядя на системном программировании AMD specification, поле ASID в блоке управления VM просто (до) 32-битный ID, который гипервизор устанавливает уникальное значение для каждый экземпляр виртуальной машины и используется как дополнительный тег в поиске TLB.
Поскольку у вас нет прямого контроля над содержимым TLB на x86, вы не можете контролировать, какие записи заканчиваются в TLB - если процессор решает добавить запись в TLB, запись будет помечена текущим ASID, который по определению будет действителен при добавлении.
Это описано в несколько окольным путем в разделе 15.15.1 из ранее упомянутой системы программирования спецификации:
В реализациях, которые не обеспечивают способ выборочно вровень указаны все переводы одного ASID, программное обеспечение может эффективно очищать записи TLB гостя путем выделения нового ASID для гостя и повторного использования старого ASID до тех пор, пока весь TLB не будет покрашен хотя бы один раз.
Это означает, что у процессора нет понятия допустимых или недействительных идентификаторов ASID - это просто номер, текущее значение которого должно соответствовать ASID TLB для TLB. Следовательно, если гипервизор неправильно очищает ASID до повторного использования, вы получите устаревшие удары TLB.