Christoffer Dall <christoffer.d...@linaro.org> 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 > kvm...@lists.cs.columbia.edu > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
