On Mon, Jul 18, 2011 at 9:18 PM, Berg, Johannes <[email protected]> wrote:
>> Today I encountered a "BUG: scheduling while atomic" from kvm.ko when
>> resuming the host from suspend-to-RAM.  I captured as much of the oops as
>> was displayed on screen:
>>
>> http://vmsplice.net/~stefan/panic1.jpg
>> http://vmsplice.net/~stefan/panic2.jpg
>>
>> It looks like the iwlagn driver may have crashed in an interrupt handler and 
>> the
>> kvm-related panic was triggered in the aftermath.  Any ideas?
>
> This doesn't look like iwlagn is involved at all -- the fact that it comes up 
> in the backtrace seems to be an artifact of backtracing not being perfect. 
> The RIP points to kvm_arch_vcpu_ioctl_run+0x927 and there's no reason to 
> believe that iwlagn should crash kvm.

RIP seems to be arch/x86/kvm/x86.c:vcpu_enter_guest():

        preempt_disable();

        kvm_x86_ops->prepare_guest_switch(vcpu);
        if (vcpu->fpu_active)
                kvm_load_guest_fpu(vcpu);
        kvm_load_guest_xcr0(vcpu);

        vcpu->mode = IN_GUEST_MODE;

        /* We should set ->mode before check ->requests,
         * see the comment in make_all_cpus_request.
         */
        smp_mb();

        local_irq_disable();

        if (vcpu->mode == EXITING_GUEST_MODE || vcpu->requests
            || need_resched() || signal_pending(current)) {
                vcpu->mode = OUTSIDE_GUEST_MODE;
                smp_wmb();
                local_irq_enable();
                preempt_enable();
                kvm_x86_ops->cancel_injection(vcpu);
                r = 1;
                goto out;
        }

        srcu_read_unlock(&vcpu->kvm->srcu, vcpu->srcu_idx);

        kvm_guest_enter();

        if (unlikely(vcpu->arch.switch_db_regs)) {
                set_debugreg(0, 7);
                set_debugreg(vcpu->arch.eff_db[0], 0);
                set_debugreg(vcpu->arch.eff_db[1], 1);
                set_debugreg(vcpu->arch.eff_db[2], 2);
                set_debugreg(vcpu->arch.eff_db[3], 3);
        }

        trace_kvm_entry(vcpu->vcpu_id);
        kvm_x86_ops->run(vcpu);

        /*
         * If the guest has used debug registers, at least dr7
         * will be disabled while returning to the host.
         * If we don't have active breakpoints in the host, we don't
         * care about the messed up debug address registers. But if
         * we have some of them active, restore the old state.
         */
        if (hw_breakpoint_active())
                hw_breakpoint_restore();

        kvm_get_msr(vcpu, MSR_IA32_TSC, &vcpu->arch.last_guest_tsc);

        vcpu->mode = OUTSIDE_GUEST_MODE;
        smp_wmb();
        local_irq_enable();  /* <--- boom! */

Stefan
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to