From mboxrd@z Thu Jan  1 00:00:00 1970
From: Alex =?utf-8?Q?Benn=C3=A9e?= <alex.bennee@linaro.org>
Subject: Re: arm: warning at virt/kvm/arm/vgic.c:1468
Date: Fri, 13 Feb 2015 06:28:12 +0000
Message-ID: <87k2zms4ub.fsf@linaro.org>
References: <54D714B9.6090106@web.de> <20150213044613.GA47577@lvm>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: Jan Kiszka <jan.kiszka@web.de>,
	Marc Zyngier <marc.zyngier@arm.com>,
	kvmarm <kvmarm@lists.cs.columbia.edu>, kvm <kvm@vger.kernel.org>
To: Christoffer Dall <christoffer.dall@linaro.org>
Return-path: <kvm-owner@vger.kernel.org>
Received: from static.88-198-71-155.clients.your-server.de ([88.198.71.155]:37252
	"EHLO socrates.bennee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751679AbbBMGoN (ORCPT <rfc822;kvm@vger.kernel.org>);
	Fri, 13 Feb 2015 01:44:13 -0500
In-reply-to: <20150213044613.GA47577@lvm>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>


Christoffer Dall <christoffer.dall@linaro.org> writes:

> Hi Jan,
>
> On Sun, Feb 08, 2015 at 08:48:09AM +0100, Jan Kiszka wrote:
>> Hi,
>>=20
>> after fixing the VM_BUG_ON, my QEMU guest on the Jetson TK1 generall=
y
>> refuses to boot. Once in a while it does, but quickly gets stuck aga=
in.
>> In one case I found this in the kernel log (never happened again so
>> far):
>>=20
>> [  762.022874] WARNING: CPU: 1 PID: 972 at ../arch/arm/kvm/../../../=
virt/kvm/arm/vgic.c:1468 kvm_vgic_sync_hwstate+0x314/0x344()
>> [  762.022884] Modules linked in:
>> [  762.022902] CPU: 1 PID: 972 Comm: qemu-system-arm Not tainted 3.1=
9.0-rc7-00221-gfd7a168-dirty #13
>> [  762.022911] Hardware name: NVIDIA Tegra SoC (Flattened Device Tre=
e)
>> [  762.022937] [<c0025d80>] (unwind_backtrace) from [<c00215d8>] (sh=
ow_stack+0x10/0x14)
>> [  762.022958] [<c00215d8>] (show_stack) from [<c065f494>] (dump_sta=
ck+0x98/0xd8)
>> [  762.022976] [<c065f494>] (dump_stack) from [<c0035f38>] (warn_slo=
wpath_common+0x80/0xb0)
>> [  762.022991] [<c0035f38>] (warn_slowpath_common) from [<c0036004>]=
 (warn_slowpath_null+0x1c/0x24)
>> [  762.023007] [<c0036004>] (warn_slowpath_null) from [<c001c3c4>] (=
kvm_vgic_sync_hwstate+0x314/0x344)
>> [  762.023024] [<c001c3c4>] (kvm_vgic_sync_hwstate) from [<c00147c0>=
] (kvm_arch_vcpu_ioctl_run+0x210/0x400)
>> [  762.023041] [<c00147c0>] (kvm_arch_vcpu_ioctl_run) from [<c001063=
c>] (kvm_vcpu_ioctl+0x2e4/0x6ec)
>> [  762.023059] [<c001063c>] (kvm_vcpu_ioctl) from [<c01098a4>] (do_v=
fs_ioctl+0x40c/0x600)
>> [  762.023076] [<c01098a4>] (do_vfs_ioctl) from [<c0109acc>] (SyS_io=
ctl+0x34/0x5c)
>> [  762.023091] [<c0109acc>] (SyS_ioctl) from [<c001e320>] (ret_fast_=
syscall+0x0/0x34)
>
> so this means your guest caused a maintenance interrupt and the bit i=
s
> set in the GICH_EISR for the LR in question but the link register sta=
te
> is not 0, which is in direct violation of the GIC spec.  Hmmmm.
>
> You're not doing any IRQ forwarding stuff or device passthrough here =
are
> you?
>
>>=20
>>=20
>> BTW, KVM tracing support on ARM seems like it requires some care. E.=
g.:
>> kvm_exit does not report an exit reason. The in-kernel vgic also see=
ms
>> to lack instrumentation. Unfortunate. Tracing is usually the first s=
top
>> when KVM is stuck on a guest.
>
> I know, the exit reason is on my todo list, and Alex B is sitting on
> trace patches for the gic.  Coming soon to a git repo near your.

=46or the impatient the raw patches are in:

git.linaro.org/people/alex.bennee/linux.git
migration/v3.19-rc7-improve-tracing

But I'll be cleaning the tracing ones up and separating them from the
rest over the next few days.

>
> -Christoffer
> _______________________________________________
> kvmarm mailing list
> kvmarm@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

--=20
Alex Benn=C3=A9e