KVM: x86: Allow marking an exception as reinjected
in [Kernel]
|
Prev: KVM: SVM: Sync cr0 and cr3 to kvm state before nested handling
Next: KVM: X86: Add callback to let modules decide over some supported cpuid bits
From: Alexander Graf on 23 Apr 2010 10:00 On 22.04.2010, at 12:33, Joerg Roedel wrote: > This patch adds logic to kvm/x86 which allows to mark an > injected exception as reinjected. This allows to remove an > ugly hack from svm_complete_interrupts that prevented > exceptions from being reinjected at all in the nested case. > The hack was necessary because an reinjected exception into > the nested guest could cause a nested vmexit emulation. But > reinjected exceptions must not intercept. The downside of > the hack is that a exception that in injected could get > lost. > This patch fixes the problem and puts the code for it into > generic x86 files because. Nested-VMX will likely have the > same problem and could reuse the code. So we always handle the reinjection from KVM code? Shouldn't the l1 hypervisor do this? Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Joerg Roedel on 23 Apr 2010 10:30 On Fri, Apr 23, 2010 at 03:57:32PM +0200, Alexander Graf wrote: > > On 22.04.2010, at 12:33, Joerg Roedel wrote: > > > This patch adds logic to kvm/x86 which allows to mark an > > injected exception as reinjected. This allows to remove an > > ugly hack from svm_complete_interrupts that prevented > > exceptions from being reinjected at all in the nested case. > > The hack was necessary because an reinjected exception into > > the nested guest could cause a nested vmexit emulation. But > > reinjected exceptions must not intercept. The downside of > > the hack is that a exception that in injected could get > > lost. > > This patch fixes the problem and puts the code for it into > > generic x86 files because. Nested-VMX will likely have the > > same problem and could reuse the code. > > So we always handle the reinjection from KVM code? Shouldn't the l1 > hypervisor do this? No. We only have the problem if we need to handle a nested intercept on the host level instead of reinjecting it. So the nested hypervisor couldn't be involved in the reinjection. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alexander Graf on 23 Apr 2010 10:50
On 23.04.2010, at 16:27, Joerg Roedel wrote: > On Fri, Apr 23, 2010 at 03:57:32PM +0200, Alexander Graf wrote: >> >> On 22.04.2010, at 12:33, Joerg Roedel wrote: >> >>> This patch adds logic to kvm/x86 which allows to mark an >>> injected exception as reinjected. This allows to remove an >>> ugly hack from svm_complete_interrupts that prevented >>> exceptions from being reinjected at all in the nested case. >>> The hack was necessary because an reinjected exception into >>> the nested guest could cause a nested vmexit emulation. But >>> reinjected exceptions must not intercept. The downside of >>> the hack is that a exception that in injected could get >>> lost. >>> This patch fixes the problem and puts the code for it into >>> generic x86 files because. Nested-VMX will likely have the >>> same problem and could reuse the code. >> >> So we always handle the reinjection from KVM code? Shouldn't the l1 >> hypervisor do this? > > No. We only have the problem if we need to handle a nested intercept on > the host level instead of reinjecting it. So the nested hypervisor > couldn't be involved in the reinjection. Hrm, makes sense. Not pretty. Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |