Подтверждение прерывания при управлении выходом в VT-x вызывает блокировку ЦП

Я работаю над поддержкой опубликованных прерываний в VMM, который я пишу, который использует виртуализацию Intel VT-x. Одно из требований к вводу в виртуальную машину, указанное в документации для разрешения опубликованных прерываний, состоит в том, что для параметра «Подтверждение прерывания при выходе» должно быть установлено значение 1.

Когда я устанавливаю этот элемент управления на 1, моя гостевая ОС работает некоторое время, прежде чем перестает отвечать. Затем ОС хоста также перестает отвечать, и в журнал ядра хоста выводится сообщение о том, что ядро ​​ЦП, на котором работала гостевая ОС, подверглось жесткой блокировке (NMI watchdog: Watchdog detected hard LOCKUP on cpu 10).

Я читаю документацию Intel и пытаюсь обдумать это, но мне было интересно, знает ли кто-нибудь еще, что происходит. Мои общие мысли прямо сейчас заключаются в том, что ОС хоста должна отправлять прерывание ядру, на котором в данный момент работает гостевая ОС (т.е. моя гостевая ОС не участвует в отправке прерывания), что вызывает выход виртуальной машины. Поскольку я установил для элемента управления «Подтверждение прерывания при выходе» значение 1, процессор подтверждает контроллеру прерывания, что прерывание было получено, и помещает вектор в поле информации о прерывании выхода VM. Более того, поскольку в настоящий момент я ничего не делаю с полем информации о прерывании в моем VMM, прерывание не обрабатывается ОС хоста, что вызывает проблему. Я иду в правильном направлении?


person Jack Humphries    schedule 30.12.2017    source источник


Ответы (1)


Да, не разрешить ОС хоста обрабатывать прерывания устройств было бы проблемой. Вместо того, чтобы устанавливать элемент управления «подтверждение прерывания при выходе» на единицу, вам, вероятно, следует установить его на 0. Затем, когда вы получаете выход виртуальной машины из-за аппаратного прерывания, вы должны установить флаг включения прерывания процессора, чтобы разрешить подтверждение и обслуживание прерывания. нормально в хосте.

Из Руководства разработчика программного обеспечения для архитектур Intel 64 и IA-32:

33.2 ОБРАБОТКА ПЕРЕРЫВОВ В РАБОТЕ VMX

  • Подтверждение прерывания при выходе. «Подтверждение прерывания при выходе» VM-управление выходом в управляющей VMCS управляет поведением процессора при подтверждении внешнего прерывания. Если управление равно 1, процессор подтверждает, что контроллер прерываний получает вектор прерывания при выходе из виртуальной машины, и сохраняет этот вектор в поле информации о прерывании выхода из виртуальной машины. Если управление равно 0, внешнее прерывание не подтверждается при выходе из VM. Поскольку RFLAGS.IF автоматически очищается при выходе из виртуальной машины из-за внешних прерываний, повторное включение прерываний VMM (установка RFLAGS.IF = 1) инициирует подтверждение внешнего прерывания и векторизацию внешнего прерывания через IDT монитора / хоста.

В качестве альтернативы, если у вас есть веская причина для установки этого бита, скажем, если вам нужно направить определенные аппаратные прерывания гостю, тогда вам нужно будет вызвать обработчик прерывания хост-ОС, как если бы он был вызван ЦП.

person Ross Ridge    schedule 30.12.2017
comment
Да, мне нужно включить это, чтобы обработка прерываний работала. Я попробую это и посмотрю, как получится. Спасибо. - person Jack Humphries; 30.12.2017
comment
Я просто добавил код для вызова правильной функции обработки прерывания Linux при выходе из виртуальной машины, вызванной внешним прерыванием, и теперь все работает. Для всех, кто интересуется, есть код, который делает это в функции vmx_handle_external_intr в arch/x86/kvm/vmx.c в проекте KVM. - person Jack Humphries; 31.12.2017
comment
@abcd, я также изучаю X86 VT-X, и я читал код, который вы упомянули в KVM, сложно понять полный контекст. У вас есть репо или образец кода для справки? Спасибо, - person wangt13; 26.08.2019
comment
@abcd, позвольте мне сначала проверить код дюны, чтобы пройти через это. Я отправлю вопрос SO, если он у меня будет. - person wangt13; 02.09.2019