Created attachment 833034 [details]
guest_call_trace_log.

guest_call_trace_log.txt(In reply to Sibiao Luo from comment #0)
> Description of problem:
> didn't add '-enable-kvm' while booting with '-no-kvm' to do vfio-pci with VF
> assigned, guest will call trace.
>
> Additional info:
> # /usr/libexec/qemu-kvm -M pc -S -cpu Opteron_G5 -no-kvm -m 2048 -smp
> 2,sockets=2,cores=1,threads=1 -no-kvm-pit-reinjection -usb -device
> usb-tablet,id=input0 -name sluo -uuid 990ea161-6b67-47b2-b803-19fb01d30d30
> -rtc base=localtime,clock=host,driftfix=slew -device
> virtio-serial-pci,id=virtio-serial0,max_ports=16,vectors=0,bus=pci.0,
> addr=0x3 -chardev socket,id=channel1,path=/tmp/helloworld1,server,nowait
> -device
> virtserialport,chardev=channel1,name=com.redhat.rhevm.vdsm,bus=virtio-
> serial0.0,id=port1 -chardev
> socket,id=channel2,path=/tmp/helloworld2,server,nowait -device
> virtserialport,chardev=channel2,name=com.redhat.rhevm.vdsm,bus=virtio-
> serial0.0,id=port2 -drive
> file=/home/RHEL-7.0-20131127.1_Server_x86_64.qcow2,if=none,id=drive-disk,
> cache=none,format=qcow2,aio=native,werror=stop,rerror=stop -device
> virtio-blk-pci,vectors=0,bus=pci.0,addr=0x4,scsi=off,drive=drive-disk,
> id=system-disk,bootindex=1 -netdev
> tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device
> virtio-net-pci,netdev=hostnet0,id=virtio-net-pci0,mac=00:01:02:B6:40:21,
> bus=pci.0,addr=0x5 -device
> virtio-balloon-pci,id=ballooning,bus=pci.0,addr=0x6 -global
> PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -k en-us -boot menu=on
> -qmp tcp:0:4444,server,nowait -serial unix:/tmp/ttyS0,server,nowait -vnc :1
> -spice disable-ticketing,port=5931 -monitor stdio -device
> vfio-pci,host=08:01.0,id=vf0
Also tried that remove "-device vfio-pci,host=08:01.0,id=vf0" from above CLI and retest that did not meet any call trace.

(In reply to Sibiao Luo from comment #0)
> Description of problem:
> didn't add '-enable-kvm' while booting with '-no-kvm' to do vfio-pci with VF
> assigned, guest will call trace.
> About the PF, please refer to Bug 1038417 - QEMU core dumped when do
> vfio-pci PF assign with '-no-kvm' mode specified (Broadcom BCM57810 card).
> 
> Version-Release number of selected component (if applicable):
> host info:
> 3.10.0-57.el7.x86_64
> qemu-kvm-1.5.3-20.el7.x86_64
> seabios-1.7.2.2-4.el7.x86_64
> guest info:
> 3.10.0-57.el7.x86_64
> 
> How reproducible:
> 100%
> 
> Steps to Reproduce:
> 1.Generate the VFs.
> # lspci | grep -i BCM57810
> 08:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM57810 10
> Gigabit Ethernet (rev 10)
> 08:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM57810 10
> Gigabit Ethernet (rev 10)
> # modprobe vfio; modprobe vfio_pci; modprobe vfio_iommu_type1
> 
> # echo 4 > /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs
> 
> # lspci | grep BCM57810
> 08:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM57810 10
> Gigabit Ethernet (rev 10)
> 08:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM57810 10
> Gigabit Ethernet (rev 10)
> 08:01.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM57810 10
> Gigabit Ethernet Virtual Function
> 08:01.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM57810 10
> Gigabit Ethernet Virtual Function
> 08:01.2 Ethernet controller: Broadcom Corporation NetXtreme II BCM57810 10
> Gigabit Ethernet Virtual Function
> 08:01.3 Ethernet controller: Broadcom Corporation NetXtreme II BCM57810 10
> Gigabit Ethernet Virtual Function
> 
> 2.Unbind the VF of BCM57810 from bnx2x and bind it to vfio-pci.
> # lspci -n -s 0000:08:01.0 | awk '{ print $3 }'
> 14e4:16af
> # echo "14e4 16af" > /sys/bus/pci/drivers/vfio-pci/new_id
> # echo 0000:08:01.0 > /sys/bus/pci/devices/0000\:08\:01.0/driver/unbind
> # echo 0000:08:01.0 > /sys/bus/pci/drivers/vfio-pci/bind
> 
> 3.Boot guest the vfio-pci assgin the VF to guest and specified *-no-kvm*.
> e.g:# /usr/libexec/qemu-kvm -M pc -cpu Opteron_G5 *-no-kvm* -m 2048 -smp
> 2,sockets=2,cores=1,threads=1 -no-kvm-pit-reinjection...-device
> vfio-pci,host=08:01.0,id=vf0
> 
> Actual results:
> after step 3, guest will call trace, i will attach all the log later.
> ...
> [  192.531972] BUG: scheduling while atomic: cryptomgr_test/537/0x10000001
> [  192.570424] Modules linked in: crc32c_intel(+) ghash_clmulni_intel
> aesni_intel lrw gf128mul glue_helper ablk_helper cryptd bnx2x microcode
> serio_raw pcspkr virtio_console virtio_balloon mdio i2c_piix4 mperf uinput
> nfsd auth_rpcgss nfs_acl lockd sunrpc xfs libcrc32c sr_mod cdrom virtio_blk
> virtio_net ata_generic cirrus pata_acpi syscopyarea sysfillrect sysimgblt
> drm_kms_helper ttm ata_piix drm virtio_pci libata i2c_core virtio_ring
> virtio floppy dm_mirror dm_region_hash dm_log dm_mod
> [  192.799740] CPU: 0 PID: 537 Comm: cryptomgr_test Not tainted
> 3.10.0-57.el7.x86_64 #1
> [  192.861475] Hardware name: Red Hat KVM, BIOS Bochs 01/01/2011
> [  192.907665]  ffff88007fc14640 ffff88007b2478c0 ffffffff815b508d
> ffff88007b2478d0
> [  192.955574]  ffffffff815af895 ffff88007b247930 ffffffff815ba5fb
> ffff88007b247fd8
> [  193.012206]  0000000000014640 ffff88007b247fd8 0000000000014640
> ffff880036c140e0
> [  193.059140] Call Trace:
> [  193.145238]  [<ffffffff815b508d>] dump_stack+0x19/0x1b
> [  193.191339]  [<ffffffff815af895>] __schedule_bug+0x4d/0x5b
> [  193.238275]  [<ffffffff815ba5fb>] __schedule+0x78b/0x790
> [  193.292295]  [<ffffffff8108cfa6>] __cond_resched+0x26/0x30
> [  193.337340]  [<ffffffff815baa2a>] _cond_resched+0x3a/0x50
> [  193.389680]  [<ffffffff81185135>] kmem_cache_alloc+0x35/0x1d0
> [  193.443453]  [<ffffffff8101b8e1>] ? init_fpu+0x81/0xb0
> [  193.448383]  [<ffffffff8101b8e1>] init_fpu+0x81/0xb0
> [  193.491532]  [<ffffffff81012c68>] math_state_restore+0x28/0x140
> [  193.491578]  [<ffffffff815bd5c5>] do_device_not_available+0x35/0x60
> [  193.491627]  [<ffffffff815c664e>] device_not_available+0x1e/0x30
> [  193.492430]  [<ffffffffa0431035>] ? crc32c_intel_le_hw+0x35/0x70
> [crc32c_intel]
> [  193.517072]  [<ffffffffa04311a1>] __crc32c_pcl_intel_finup+0x31/0xa0
> [crc32c_intel]
> [  193.517124]  [<ffffffffa0431242>] crc32c_pcl_intel_finup+0x12/0x20
> [crc32c_intel]
> [  193.517168]  [<ffffffff812604af>] crypto_shash_finup+0x1f/0x40
> [  193.517203]  [<ffffffff81260b4b>] shash_ahash_finup+0x3b/0x90
> [  193.517256]  [<ffffffff81260c90>] shash_ahash_digest+0xc0/0xe0
> [  193.517293]  [<ffffffff81260cb0>] ? shash_ahash_digest+0xe0/0xe0
> [  193.517909]  [<ffffffff81260cd4>] shash_async_digest+0x24/0x30
> [  193.551854]  [<ffffffff8125fe5a>] crypto_ahash_op+0x2a/0xc0
> [  193.551899]  [<ffffffff8125ff46>] crypto_ahash_digest+0x16/0x20
> [  193.551935]  [<ffffffff81262d32>] test_hash+0x3c2/0x7d0
> [  193.551988]  [<ffffffff81260e07>] ? crypto_init_shash_ops_async+0x37/0xe0
> [  193.552039]  [<ffffffff8125fab7>] ? crypto_ahash_init_tfm+0x37/0xb0
> [  193.552077]  [<ffffffff812592e3>] ? crypto_create_tfm+0x43/0xd0
> [  193.589041]  [<ffffffff81263182>] alg_test_hash+0x42/0xa0
> [  193.589082]  [<ffffffff81263202>] alg_test_crc32c+0x22/0x130
> [  193.589117]  [<ffffffff81262373>] ? alg_find_test+0x43/0x90
> [  193.589153]  [<ffffffff812624a9>] alg_test+0xe9/0x300
> [  193.589213]  [<ffffffff815ba135>] ? __schedule+0x2c5/0x790
> [  193.589863]  [<ffffffff81261010>] ? crypto_unregister_pcomp+0x20/0x20
> [  193.625363]  [<ffffffff81261051>] cryptomgr_test+0x41/0x50
> [  193.625413]  [<ffffffff8107eb60>] kthread+0xc0/0xd0
> [  193.625452]  [<ffffffff8107eaa0>] ? kthread_create_on_node+0x110/0x110
> [  193.625494]  [<ffffffff815c4e2c>] ret_from_fork+0x7c/0xb0
> [  193.625531]  [<ffffffff8107eaa0>] ? kthread_create_on_node+0x110/0x110
> [  193.626215] [sched_delayed] sched: RT throttling activated
> [  195.150533] alg: No test for crc32 (crc32-pclmul)
> ...
> 
> Expected results:
> the best is that guest failed to boot up and qemu quit due to: 'vfio-pci
> error: requires KVM support'.

I think that the guest should be able to boot with vfio even without kvm, vfio is a separate driver independent of kvm. The device may not initialize for some reason, but I don't think the guest will quit (verified it myself on my system)

(In reply to Bandan Das from comment #4)
> (In reply to Sibiao Luo from comment #0)
> > Expected results:
> > the best is that guest failed to boot up and qemu quit due to: 'vfio-pci
> > error: requires KVM support'.
> 
> I think that the guest should be able to boot with vfio even without kvm,
> vfio is a separate driver independent of kvm. The device may not initialize
> for some reason, but I don't think the guest will quit (verified it myself
> on my system)

Agree with you, but guest call trace is not acceptable. Here i just gave a simple suggestion to avoid the call trace which guest failed to boot up and qemu quit with a warning message due to: 'vfio-pci error: requires KVM support'.
Since the vfio is a separate driver independent of kvm, it's better to fix this bug to avoid the guest call trace. Thanks in advance.

Best Regards,
sluo

Based on my testing in comment 8, I am closing this and believe this is one of the many cases of a messed up config space that results when booting guest with option rom enabled. Since the test case itself does not need to be run with option rom enabled, I think we can close it safely. Feel free to reopen if you think otherwise.

(In reply to Bandan Das from comment #9)
> Based on my testing in comment 8, I am closing this and believe this is one
> of the many cases of a messed up config space that results when booting
> guest with option rom enabled. Since the test case itself does not need to
> be run with option rom enabled, I think we can close it safely. Feel free to
> reopen if you think otherwise.

OK, thanks for your checking, we can reopen it if meet it again.