Alexander Graf wrote:
Avi Kivity wrote:
Alexander Graf wrote:
I have CONFIG_LOCKDEP_SUPPORT=y. How do I make it detect that it's
actually locking itself up?
Btw: The issue seems to be easily reproducible :-)
Perhaps CONFIG_PROVE_LOCKING and CONFIG_LOCKDEP. _SUPPORT just
indicates the arch can do it if you want, IIUC.
I just added some debug #define's to show me where exactly things break.
Jan 7 14:34:46 linux-dp8n kernel: 2149: Grabbing lock {
Jan 7 14:34:46 linux-dp8n kernel: 1908: Grabbing lock {
2145 mmio:
2146 /*
2147 * Is this MMIO handled locally?
2148 */
2149 mutex_lock(&vcpu->kvm->lock);
2150 mmio_dev = vcpu_find_mmio_dev(vcpu, gpa, bytes, 0);
2151 if (mmio_dev) {
2152 kvm_iodevice_read(mmio_dev, gpa, bytes, val);
2153 mutex_unlock(&vcpu->kvm->lock);
2154 return X86EMUL_CONTINUE;
2155 }
2156 mutex_unlock(&vcpu->kvm->lock);
The lock was lost here. But how?
1901 case KVM_IRQ_LINE: {
1902 struct kvm_irq_level irq_event;
1903
1904 r = -EFAULT;
1905 if (copy_from_user(&irq_event, argp, sizeof
irq_event))
1906 goto out;
1907 if (irqchip_in_kernel(kvm)) {
1908 mutex_lock(&kvm->lock);
1909 kvm_set_irq(kvm,
KVM_USERSPACE_IRQ_SOURCE_ID,
1910 irq_event.irq, irq_event.level);
1911 mutex_unlock(&kvm->lock);
1912 r = 0;
1913 }
1914 break;
1915 }
This is your hung iothread trying to inject an interrupt. It's waiting
for the lost lock.
I suggest enabling all the lock debug magic you can find in kconfig.
--
error compiling committee.c: too many arguments to function
--
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
