Bug 1449067

Summary: [RFE] Device passthrough support for VT-d emulation
Product: Red Hat Enterprise Linux 7 Reporter: Peter Xu <peterx>
Component: qemu-kvm-rhevAssignee: Peter Xu <peterx>
Status: CLOSED ERRATA QA Contact: Yanan Fu <yfu>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.4CC: chayang, hhuang, jinzhao, juzhang, knoel, michen, mtessun, peterx, pezhang, virt-maint, yfu
Target Milestone: rcKeywords: FutureFeature
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: qemu-kvm-rhev-2.10.0-3.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-11 00:19:31 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:
Embargoed:

Description Peter Xu 2017-05-09 07:44:16 UTC
Description of problem:

VT-d has special support for passthrough mode. Let's support that feature in our VT-d emulation.

That'll benefit us when guest is using "iommu=pt" mode. We'll avoid having an identity mapping, which will not only lock up all guest memory, but also slower than hardware passthrough mode (which is what we are going to support).

Version-Release number of selected component (if applicable):

N/A

How reproducible:

N/A

Steps to Reproduce:

(hardware passthrough mode is not only for vfio-pci device, but here we use this device to detect whether it's working by observing some warning messages)

Start guest with vfio-pci device:

bin=x86_64-softmmu/qemu-system-x86_64
$bin -M q35,accel=kvm,kernel-irqchip=split -m 2G \
     -device intel-iommu,intremap=on,caching-mode=on \
     -device vfio-pci,host=00:19.0 \
     /var/lib/libvirt/images/fedora-25.qcow2

Actual results:

When without passthrough mode support, we'll see some warnings like:

  qemu-system-x86_64: iommu has granularity incompatible with target AS

or/and:

  qemu-system-x86_64: iommu map to non memory area 180000000

Expected results:

See no warnings. (Actually, guest will boot slightly faster)

Comment 2 Peter Xu 2017-05-09 07:46:36 UTC
Current upstream work:

https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg02583.html

Comment 3 Peter Xu 2017-05-10 11:43:48 UTC
The block field is incorrect. I was meaning bug 1448813, but now I would prefer no dependency since we'll postpone this bug to 7.5 and we need to solve the crash in bug 1448813. 

As a conclusion, I'm removing the blocker.

Comment 8 Miroslav Rezanina 2017-10-20 09:31:58 UTC
Fix included in qemu-kvm-rhev-2.10.0-3.el7

Comment 10 Yanan Fu 2017-11-22 09:29:20 UTC
qemu command line:
/usr/libexec/qemu-kvm \
-M q35,accel=kvm,kernel-irqchip=split \
-m 2G \
-cpu SandyBridge,enforce \
-device intel-iommu,intremap=on,caching-mode=on,id=viommu \
-device pcie-root-port,id=root0,slot=1 \
-device pcie-root-port,id=root1,slot=2 \
-drive file=/home/rhel74-64-virtio.qcow2,if=none,id=drive-virtio-blk-disk,format=qcow2,cache=none \
-device virtio-blk-pci,bus=root0,drive=drive-virtio-blk-disk \
-monitor stdio \
-vga qxl \
-vnc :0 \
-device vfio-pci,host=83:00.0,id=pf,rombar=0,bus=root1 \


Test steps:
1. Prepare a guest with "intel_iommu=on iommu=pt" in kernel line
2. Boot the vm with the command line above, key device:
-M q35,accel=kvm,kernel-irqchip=split \
-device intel-iommu,intremap=on,caching-mode=on,id=viommu \
-device vfio-pci,host=83:00.0,id=pf,rombar=0,bus=root1 \


---------------------reproduce---------------
Reproduce this bz with RHEL7.4.z, as this issue exist before rebase to 2.10.
Test version:
qemu-kvm: qemu-img-rhev-2.9.0-16.el7_4.10.x86_64

After during guest booting, qemu monitor promote:
(qemu) qemu-kvm: iommu has granularity incompatible with target AS

reproduce this issue successfully.

---------------------verification---------------
Test version:
qemu-kvm: qemu-kvm-rhev-2.10.0-3.el7

Guest can boot up without the warning, and run normally.


According to the test result above, move to VERIFIED.

Comment 12 errata-xmlrpc 2018-04-11 00:19:31 UTC
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