Running Oneiric kernel as Xen HVM guest with pvlocks hangs on boot
Bug #838026 reported by
Stefan Bader
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
High
|
Stefan Bader | ||
Oneiric |
Fix Released
|
High
|
Stefan Bader |
Bug Description
Since xen-4.1.1 the hypervisor supports callback vectors. This causes newer kernels to try using IPIs and spinlocks in a paravirtualized way. However booting with such a kernel (2.6.39 or newer) hangs on boot. With only the pv spinlocks disabled, the boot succeeds.
Adding additional debug shows that the floppy_lock is released through the pv method, but it never seems to have been taken that way. The contents of the lock look like it was taken by the default ticket_spinlock method.
Changed in linux (Ubuntu): | |
status: | New → In Progress |
assignee: | nobody → Stefan Bader (stefan-bader-canonical) |
importance: | Undecided → High |
Changed in linux (Ubuntu Oneiric): | |
status: | In Progress → Fix Committed |
To post a comment you must log in.
From the raw crash dump here is the lock/set_ next_request/ unlock sequence. Note that
this has had its locking primatives rewritten as direct calls where inline (for the unlock):
ffffffffa0020df0: 00 e9 ed fe ff ff 66 2e 0f 1f 84 00 00 00 00 00 ......f.........
e8 74 c3 5d e1 request+ 0x17c>
e8 cf a7 ff H...^...t.].....
66 90 fb 66 66 .L.....%...f..ff
ffffffffa0020e00: 48 c7 c7 f8 5e 02 a0
6e00: 48 c7 c7 00 00 00 00 mov $0x0,%rdi
6e07: e8 00 00 00 00 callq 6e0c <redo_fd_
FFFFFFFFA0020E0C + FFFFFFFFE15DC374 => FFFFFFFF815FD180
ffffffff815fd180 (T) _raw_spin_lock_irq
ffffffffa0020e10: ff
6e0c: e8 cf a7 ff ff callq 15e0 <set_next_request>
ffffffffa0020e10: 4c 89 e7
6e11: 4c 89 e7 mov %r12,%rdi
ffffffffa0020e10: 89 c3
6e14: 89 c3 mov %eax,%ebx
ffffffffa0020e10: e8 25 83 fe e0
6e16: ff 14 25 00 00 00 00 callq *0x0
NOTE: this has been rewritten as a callq
FFFFFFFFA0020E1B + FFFFFFFFE0FE8325 => FFFFFFFF81009140
ffffffff81009140 (t) xen_spin_unlock
ffffffffa0020e20: 90 66 66 90 85 db 0f 84 1c 01 00 00 48 8b 05 bd .ff.........H...
Looking at the out-of-line lock this has been written as the ticket version:
12:37:31 smb | 0xffffffff815fd180 <_raw_spin_ lock_irq+ 0>: push %rbp lock_irq+ 1>: mov %rsp,%rbp lock_irq+ 4>: xchg %ax,%ax lock_irq+ 9>: cli lock_irq+ 10>: xchg %ax,%ax lock_irq+ 13>: xchg %ax,%ax lock_irq+ 16>: callq 0xffffffff81033900 <__ticket_ spin_lock> lock_irq+ 21>: xchg %ax,%ax lock_irq+ 23>: pop %rbp lock_irq+ 24>: retq
12:37:31 smb | 0xffffffff815fd181 <_raw_spin_
12:37:31 smb | 0xffffffff815fd184 <_raw_spin_
12:37:31 smb | 0xffffffff815fd189 <_raw_spin_
12:37:32 smb | 0xffffffff815fd18a <_raw_spin_
12:37:34 smb | 0xffffffff815fd18d <_raw_spin_
12:37:36 smb | 0xffffffff815fd190 <_raw_spin_
12:37:40 smb | 0xffffffff815fd195 <_raw_spin_
12:37:42 smb | 0xffffffff815fd197 <_raw_spin_
12:37:44 smb | 0xffffffff815fd198 <_raw_spin_
Proving smb's conjecture we are locking with ticket and unlocking with xen paravirt locks. As the lock and unlock are not the same form, explosions are inevitable.