It seems that running any kind of nested VM with kvm, even with the
"default" qemu (running just like in the docs, EDKII with acpi=on and
-enable-kvm added) just hangs forever at boot:
```
[ 37.214239] Modules linked in:
[ 37.215434] Sending NMI from CPU 0 to CPUs 1:
[ 108.183642] rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks:
{ 1-...D } 15106 jiffies s: 37 root: 0x2/.
[ 108.350649] rcu: blocking rcu_node structures (internal RCU debug):
[ 108.429119] Sending NMI from CPU 0 to CPUs 1:
[ 243.344247] INFO: task rcu_exp_gp_kthr:17 blocked for more than 120 seconds.
[ 243.432583] Not tainted 7.0.0-14-generic #14.2-Ubuntu
[ 243.510526] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 243.628189] task:rcu_exp_gp_kthr state:D stack:0 pid:17 tgid:17
ppid:2 task_flags:0x208040 flags:0x00000000
[ 243.799918] Call Trace:
[ 243.844274] [<ffffffffb403ef52>] __schedule+0x36a/0x908
[ 243.918905] [<ffffffffb403f51e>] schedule+0x2e/0xb0
[ 243.988392] [<ffffffffb404724c>] schedule_timeout+0x84/0x128
[ 244.073422] [<ffffffffb311de8e>] synchronize_rcu_expedited_wait+0xa6/0x310
[ 244.174565] [<ffffffffb3120146>] rcu_exp_wait_wake+0x1e/0x140
[ 244.262008] [<ffffffffb3120294>] wait_rcu_exp_gp+0x2c/0x40
[ 244.343615] [<ffffffffb3078f46>] kthread_worker_fn+0xa6/0x320
[ 244.435730] [<ffffffffb3077d7a>] kthread+0xfa/0x130
[ 244.511148] [<ffffffffb301fdf0>] ret_from_fork_kernel+0x20/0x2e8
[ 244.602532] [<ffffffffb404b236>] ret_from_fork_kernel_asm+0x16/0x18
```
Switching to ACPI=off works perfectly. Something definitely seems to be
wrong with ACPI, either in the kernel or qemu.
On questing, I get the same kind of "stuck" behaviour - the bug also
happens on a 6.17 kernel.
With no nest and no kvm, the bug does not happen.
Nested VM without kvm also seems to work.
Something seems wrong in the way that KVM handles ACPI. It is still
unclear whether this is an issue in qemu or in the kernel, but I think
this is a real bug as it should work with default config.
What would be interesting: does it work with kvm on the k3? If so, it
has to do with the way that QEMU emulates kvm / the H extension.
PS: This is not exactly the same issue with the "sysfs: ..." log, but
given that the sysfs log is not followed by a kernel panic it seems that
it continues to boot but hangs just like described.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2153582
Title:
sysfs: cannot create duplicate filename
'/devices/pci0000:00/0000:00:01.1/resource0'
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-riscv/+bug/2153582/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
