Software Archive
Read-only legacy content
17061 Discussions

Redirecting host interrupts to the guest

hellfire
New Contributor I
565 Views
I am implementing thin hypervisor which runs under primary OS which is executed as guest. To implement such things as shadow paging I need hardware interrupts to be enabled in the host. I am trying to set a coresponding bit in the bitmap for each hardware interrupt delivered through the host IDT. On VM entry I am injecting to the guest all interrupts which have happened during VM exit processing and have corresponding bits set in the bitmap. Interrupts with higher priorities are injected first.

Everything works fine, but sometimes (very rarely) guest hangs without VM exits committed.

Question to experts: is this design right and what could be a reason for the hang?
0 Kudos
1 Solution
David_O_Intel1
Employee
565 Views
Here are some comments that I received. Note that your key resource in this arena is Volume 3A of Intel 64 and IA-32 Architectures Software Developers Manual at http://www.intel.com/products/processor/manuals/

"The thin hypervisor described uses a bitmap to track interrupts that it receives that should be delivered to the primary OS. This bitmap virtualizes the functionality of the local APIC's interrupt-request register (IRR).

While this can form the foundation of a robust approach, there may be issues related to interactions with other aspects of the local APIC's interrupt prioritization logic. For example, the hypervisor should take care not to deliver to the primary OS interrupts whose priority class is not greater than PPR[7:4] (see Section 10.9.3.1 of Volume 3A of Intel 64 and IA-32 Architectures Software Developers Manual).

If the hypervisor's use of the local APIC results in the hardware's value of PPR being different than that which the primary OS would see in the absence of the hypervisor (this may occur, for example, if a hypervisor interrupt is in service), the hypervisor may need to virtualize much of the local APIC's interrupt-prioritization logic (Section 10.9.3). Doing so may be quite complex.

It may also be necessary for the hypervisor to intercept the primary OS's reads and writes of the local APIC's control registers (e.g., to ensure that the primary OS's operation is not improperly perturbed by the hypervisor's use of the local APIC).

It is possible that delivery of an unexpected interrupt to the primary OS or some other failure to virtualize properly the behavior of the local APIC may perturb operation of the primary OS to the point that it hangs. It is hard to say for certain without knowing more details about how the hypervisor and the primary OS operates."

David Ott

View solution in original post

0 Kudos
3 Replies
David_O_Intel1
Employee
565 Views
Am following up internally about this. Stay tuned.

David Ott

0 Kudos
David_O_Intel1
Employee
566 Views
Here are some comments that I received. Note that your key resource in this arena is Volume 3A of Intel 64 and IA-32 Architectures Software Developers Manual at http://www.intel.com/products/processor/manuals/

"The thin hypervisor described uses a bitmap to track interrupts that it receives that should be delivered to the primary OS. This bitmap virtualizes the functionality of the local APIC's interrupt-request register (IRR).

While this can form the foundation of a robust approach, there may be issues related to interactions with other aspects of the local APIC's interrupt prioritization logic. For example, the hypervisor should take care not to deliver to the primary OS interrupts whose priority class is not greater than PPR[7:4] (see Section 10.9.3.1 of Volume 3A of Intel 64 and IA-32 Architectures Software Developers Manual).

If the hypervisor's use of the local APIC results in the hardware's value of PPR being different than that which the primary OS would see in the absence of the hypervisor (this may occur, for example, if a hypervisor interrupt is in service), the hypervisor may need to virtualize much of the local APIC's interrupt-prioritization logic (Section 10.9.3). Doing so may be quite complex.

It may also be necessary for the hypervisor to intercept the primary OS's reads and writes of the local APIC's control registers (e.g., to ensure that the primary OS's operation is not improperly perturbed by the hypervisor's use of the local APIC).

It is possible that delivery of an unexpected interrupt to the primary OS or some other failure to virtualize properly the behavior of the local APIC may perturb operation of the primary OS to the point that it hangs. It is hard to say for certain without knowing more details about how the hypervisor and the primary OS operates."

David Ott
0 Kudos
oliverlnrd
Beginner
565 Views
Thanx for sharing

http://www.paddockpro.com
0 Kudos
Reply