- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
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?
1 Solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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"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."
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Am following up internally about this. Stay tuned.
David Ott
David Ott
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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"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."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page