- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
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 솔루션
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
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."
링크가 복사됨
3 응답
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
Am following up internally about this. Stay tuned.
David Ott
David Ott
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
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."
