On Thu, Feb 19, 2015 at 05:02:22PM +0100, Radim Krčmář wrote:
> 2015-02-19 16:01+0100, Radim Krčmář:
> > 2015-02-19 13:07+0100, Kashyap Chamarthy:
> > 5f3d5799974b8 KVM: nVMX: Rework event injection and recovery:
> > This concept is based on the rule that a pending vmlaunch/vmresume is
> > not canceled. Otherwise, we would risk to lose injected events or leak
> > them into the wrong queues. Encode this rule via a WARN_ON_ONCE at the
> > entry of nested_vmx_vmexit.
> >
> > I wonder if we have broken the invariant since 3.9 ...
>
> e011c663b9c786d115c0f45e5b0bfae0c39428d4
> KVM: nVMX: Check all exceptions for intercept during delivery to L2
>
> All exceptions should be checked for intercept during delivery to L2,
> but we check only #PF currently. Drop nested_run_pending while we are
> at it since exception cannot be injected during vmentry anyway.
>
> The last sentence is not true.
>
> Can you try if the following patch works?
Sure, will test a Kernel built with the below patch and report back.
Thanks for taking a look.
--
/kashyap
> (I know little about nested, so it might be introducing another bug.)
>
> Thanks.
>
> ---8<---
> KVM: nVMX: fix L2 to L1 interrupt leak
>
> When vmx->nested.nested_run_pending is set, we aren't expected to exit
> to L1, but nested_vmx_check_exception() could, since e011c663b9c7.
> Prevent that.
>
> Fixes: e011c663b9c7 ("Check all exceptions for intercept during delivery to L2")
> Signed-off-by: Radim Krčmář <rkrcmar@xxxxxxxxxx>
> ---
> arch/x86/kvm/vmx.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 3f73bfad0349..389166a1b79a 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -2098,6 +2098,9 @@ static int nested_vmx_check_exception(struct kvm_vcpu *vcpu, unsigned nr)
> {
> struct vmcs12 *vmcs12 = get_vmcs12(vcpu);
>
> + if (to_vmx(vcpu)->nested.nested_run_pending)
> + return 0;
> +
> if (!(vmcs12->exception_bitmap & (1u << nr)))
> return 0;
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
