I bisected this down to the upstream commit below. Now, that's not to
say that this commit is necessarily bad - it may just make an existing
problem more reproducible.
commit 7235acdb1144460d9f520f0d931f3cbb79eb244c
Author: Jason Wang <jasow...@redhat.com>
Date: Mon Apr 25 22:14:32 2016 -0400
vhost: simplify work flushing
We used to implement the work flushing through tracking queued seq,
done seq, and the number of flushing. This patch simplify this by just
implement work flushing through another kind of vhost work with
completion. This will be used by lockless enqueuing patch.
Signed-off-by: Jason Wang <jasow...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1673564
Title:
ThunderX: soft lockup on 4.8+ kernels when running qemu-efi with
vhost=on
Status in edk2 package in Ubuntu:
Confirmed
Status in linux package in Ubuntu:
Confirmed
Bug description:
This is a followup of an earlier thread/bug that we have narrowed down
to an incompatibility/issue with vhost support in qemu-efi. Without
vhost=on qemu seems to be working fine.
I have tested several edk2 firmwares:
- xenial
- zesty
- Fedora:
ftp://195.220.108.108/linux/fedora-secondary/development/rawhide/Everything/aarch64/os/Packages/e/edk2-aarch64-20170209git296153c5-2.fc26.noarch.rpm
I have also tested with different guests:
- cirros:
https://download.cirros-cloud.net/daily/20161201/cirros-d161201-aarch64-disk.img
- ubuntu xenial:
https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-arm64-uefi1.img
The test steps are simple enough. A tap device is needed, qemu-kvm,
qemu-efi need to be installed. The UEFI iamge is run as shown in the
launch.sh script, the tap device is used in vhost=on mode.
Also note that the QEMU_EFI.fd binary needs to be padded up to 64M:
dd if=/dev/zero of=AAVMF_CODE.fd bs=1M count=64
dd if=QEMU_EFI.fd of=AAVMF_CODE.fd conv=notrunc
The result was always the same, the node crashing with soft-lockups when qemu
was attempting to boot the kernel.
I will attach all the relevant information shortly.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1673564/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
