| Summary: | guest will call trace when boot it with VF vfio-pci assigned with '-no-kvm' mode specified (Broadcom BCM57810 card) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Sibiao Luo <sluo> | ||||
| Component: | qemu-kvm | Assignee: | Bandan Das <bdas> | ||||
| Status: | CLOSED WORKSFORME | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 7.0 | CC: | acathrow, alex.williamson, chayang, hhuang, juzhang, michen, qzhang, sluo, virt-maint, xfu | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2014-01-23 13:18:24 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
|
Description
Sibiao Luo
2013-12-05 07:56:05 UTC
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. |