Red Hat Bugzilla – Bug 1476121
Unable to start vhost if iommu_platform=on but intel_iommu=on not specified in guest
Last modified: 2018-04-10 20:30:00 EDT
Description of problem: Boot VM with vhost dmar, but setup guest cmdline without "intel_iommu=on": bin=x86_64-softmmu/qemu-system-x86_64 $bin -M q35,kernel-irqchip=split -enable-kvm -m 4G -smp 4 -monitor stdio \ -device intel-iommu,intremap=on,device-iotlb=on \ -device ioh3420,id=pcie.1,chassis=1 \ -device virtio-net-pci,bus=pcie.1,netdev=net0,disable-legacy=on,disable-modern=off,iommu_platform=on,ats=on \ -netdev tap,id=net0,vhostforce \ /images/fedora-25.qcow2 We'll get this: qemu-system-x86_64: unable to start vhost net: 14: falling back on userspace virtio It is fixed upstream but not yet in downstream: aef5ffd exec: abstract address_space_do_translate() Version-Release number of selected component (if applicable): Latest qemu-kvm-rhev How reproducible: 100% Steps to Reproduce: See above Actual results: vhost cannot start successfully Expected results: vhost can start as usual Additional info: N/A
(In reply to Peter Xu from comment #0) > It is fixed upstream but not yet in downstream: > > aef5ffd exec: abstract address_space_do_translate() The right SHA1 is a764040cc831cfe5b8bf1c80e8341b9bf2de3ce8: commit a764040cc831cfe5b8bf1c80e8341b9bf2de3ce8 Author: Peter Xu <peterx@redhat.com> Date: Wed May 17 16:57:42 2017 +0800 exec: abstract address_space_do_translate() This function is an abstraction helper for address_space_translate() and address_space_get_iotlb_entry(). It does the lookup of address into memory region section, then does proper IOMMU translation if necessary. Refactor the two existing functions to use it. This fixes vhost when IOMMU is disabled by guest. Tested-by: Maxime Coquelin <maxime.coquelin@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
1. boot a guest # /usr/libexec/qemu-kvm \ -name 'virt-tests-vm2' -sandbox off -machine q35,kernel-irqchip=split -vga std \ -drive id=drive_image1,if=none,snapshot=on,aio=threads,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/rhel74-64-virtio.qcow2 -device virtio-blk-pci,id=image1,drive=drive_image1 \ -device intel-iommu,intremap=on,device-iotlb=on -device ioh3420,id=pcie.1,chassis=1 -device virtio-net-pci,mac=9a:86:87:88:89:8a,id=idRB0WNk,vectors=4,netdev=idb3O1YX,disable-legacy=on,disable-modern=off,iommu_platform=on,ats=on -netdev tap,id=idb3O1YX,vhost=on,script=/etc/ovs-ifup,downscript=/etc/ovs-ifdown,vhostforce \ -m 8192 -smp 8 -cpu 'Haswell-noTSX',+kvm_pv_unhalt,hv_spinlocks=0x1fff,hv_vapic,hv_time -vnc :1 -rtc base=localtime,clock=host,driftfix=slew -enable-kvm -monitor stdio 2. check output of qemu command line QEMU 2.10.0 monitor - type 'help' for more information (qemu) Set to 'Verified'.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:1104