Re: arm: warning at virt/kvm/arm/vgic.c:1468

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Christoffer Dall <christoffer.dall@xxxxxxxxxx> writes:

> Hi Jan,
>
> On Sun, Feb 08, 2015 at 08:48:09AM +0100, Jan Kiszka wrote:
>> Hi,
>> 
>> after fixing the VM_BUG_ON, my QEMU guest on the Jetson TK1 generally
>> refuses to boot. Once in a while it does, but quickly gets stuck again.
>> In one case I found this in the kernel log (never happened again so
>> far):
>> 
>> [  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.19.0-rc7-00221-gfd7a168-dirty #13
>> [  762.022911] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
>> [  762.022937] [<c0025d80>] (unwind_backtrace) from [<c00215d8>] (show_stack+0x10/0x14)
>> [  762.022958] [<c00215d8>] (show_stack) from [<c065f494>] (dump_stack+0x98/0xd8)
>> [  762.022976] [<c065f494>] (dump_stack) from [<c0035f38>] (warn_slowpath_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 [<c001063c>] (kvm_vcpu_ioctl+0x2e4/0x6ec)
>> [  762.023059] [<c001063c>] (kvm_vcpu_ioctl) from [<c01098a4>] (do_vfs_ioctl+0x40c/0x600)
>> [  762.023076] [<c01098a4>] (do_vfs_ioctl) from [<c0109acc>] (SyS_ioctl+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 is
> set in the GICH_EISR for the LR in question but the link register state
> 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?
>
>> 
>> 
>> 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 seems
>> to lack instrumentation. Unfortunate. Tracing is usually the first stop
>> 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.

For 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@xxxxxxxxxxxxxxxxxxxxx
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

-- 
Alex Bennée
--
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




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux