[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150520181945.GA20853@canonical.com>
Date: Wed, 20 May 2015 11:19:45 -0700
From: Chris J Arges <chris.j.arges@...onical.com>
To: Ingo Molnar <mingo@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Rafael David Tinoco <inaddy@...ntu.com>,
Peter Anvin <hpa@...or.com>,
Jiang Liu <jiang.liu@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
LKML <linux-kernel@...r.kernel.org>,
Jens Axboe <axboe@...nel.dk>,
Frederic Weisbecker <fweisbec@...il.com>,
Gema Gomez <gema.gomez-solano@...onical.com>,
the arch/x86 maintainers <x86@...nel.org>
Subject: Re: [PATCH] smp/call: Detect stuck CSD locks
On Mon, May 11, 2015 at 04:00:03PM +0200, Ingo Molnar wrote:
> > So potentially, CPU0 generated an interrupt that caused
> > vcpu_enter_guest to be called on CPU1. However, when
> > vmx_handle_external_intr was called, it didn't progress any further.
>
> So the IPI does look like to be lost in the KVM code?
>
> So why did vmx_handle_external_intr() skip the irq injection - were
> IRQs disabled in the guest perhaps?
>
> > Another experiment here would be to dump
> > vmcs_read32(VM_EXIT_INTR_INFO); to see why we don't handle the
> > interrupt.
>
> Possibly, but also to instrument the KVM IRQ injection code to see
> when it skips an IPI and why.
>
> Thanks,
>
> Ingo
>
Ingo,
I no longer have access to the reproducer machine unfortunately. I'll try to
locate additional kit that has the same situation, but it may take some time.
Thanks,
--chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists