Bug 1597482 - qemu crashed when disk enable the IOMMU
Summary: qemu crashed when disk enable the IOMMU
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.6
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: John Snow
QA Contact: Xueqiang Wei
URL:
Whiteboard:
: 1599237 (view as bug list)
Depends On: 1547940
Blocks: 1686278 1597525
TreeView+ depends on / blocked
 
Reported: 2018-07-03 03:25 UTC by yafu
Modified: 2019-08-22 09:19 UTC (History)
16 users (show)

Fixed In Version: qemu-kvm-rhev-2.12.0-24.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1597525 1686278 (view as bug list)
Environment:
Last Closed: 2019-08-22 09:18:46 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:2553 None None None 2019-08-22 09:19:41 UTC

Description yafu 2018-07-03 03:25:15 UTC
Description of problem:
qemu crashed when disk enable the IOMMU for virtio-scsi

Version-Release number of selected component (if applicable):
libvirt-4.4.0-2.el7.x86_64
qemu-kvm-rhev-2.12.0-6.el7.x86_64

How reproducible:
100%

Steps to reproduce:
1.Enable iommu in the guest os:
(1)Edit file  "/etc/default/grub":
Append "intel_iommu=on" or "amd_iommu=on" to the value of "GRUB_CMDLINE_LINUX=......". Such as the following one:
GRUB_CMDLINE_LINUX="rd.md=0 rd.lvm=0 rd.dm=0 vconsole.keymap=us $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) rd.luks=0 vconsole.font=latarcyrheb-sun16 rhgb quiet intel_iommu=on"

(2)Then run the following command to generate the updated grub file:
# grub2-mkconfig -o /boot/grub2/grub.cfg
Shutdown the guest.

2.Edit guest xml to enabel the IOMMU for virtio-scsi disk:
#virsh dumpxml iommu1
  <features>
   <ioapic driver='qemu'/>
 </features>
 ...
   <os>
    <type arch='x86_64' machine='pc-q35-rhel7.5.0'>hvm</type>
    <boot dev='hd'/>
  </os>
..
<device>
<disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='none'/>
      <source file='/mnt/yafu/V-75.qcow2'/>
      <target dev='sda' bus='scsi'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
...
 <controller type='scsi' index='0' model='virtio-scsi'>
      <driver iommu='on' ats='on'/>
      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
    </controller>

...
   <iommu model='intel'>
      <driver intremap='on' caching_mode='on' eim='on' iotlb='on'/>
    </iommu>
</device>

3.Start the guest:
#virsh start iommu1

Actual results:
qemu crashed after a few seconds.


Expected results:
Guest should works well.

Additional info:
1.The backtrace of qemu process:
(gdb) bt
#0  0x00007f4a2847c207 in raise () from /lib64/libc.so.6
#1  0x00007f4a2847d8f8 in abort () from /lib64/libc.so.6
#2  0x0000562dfe23dd9a in qemu_get_ram_block (addr=<optimized out>) at /usr/src/debug/qemu-2.12.0/exec.c:1115
#3  0x0000562dfe241b45 in qemu_map_ram_ptr (ram_block=<optimized out>, addr=18446744073709542208) at /usr/src/debug/qemu-2.12.0/exec.c:2288
#4  0x0000562dfe247ff5 in address_space_lduw_internal_cached (cache=<optimized out>, cache=<optimized out>, endian=DEVICE_LITTLE_ENDIAN, result=0x0, attrs=..., addr=2)
    at /usr/src/debug/qemu-2.12.0/memory_ldst.inc.c:281
#5  address_space_lduw_le_cached (result=0x0, attrs=..., addr=2, cache=<optimized out>) at /usr/src/debug/qemu-2.12.0/memory_ldst.inc.c:315
#6  lduw_le_phys_cached (cache=<optimized out>, addr=addr@entry=2) at /usr/src/debug/qemu-2.12.0/memory_ldst.inc.c:334
#7  0x0000562dfe2db3fc in virtio_lduw_phys_cached (vdev=<optimized out>, pa=2, cache=<optimized out>) at /usr/src/debug/qemu-2.12.0/include/hw/virtio/virtio-access.h:166
#8  vring_avail_idx (vq=0x562e02f44100) at /usr/src/debug/qemu-2.12.0/hw/virtio/virtio.c:228
#9  virtio_queue_empty (vq=0x562e02f44100) at /usr/src/debug/qemu-2.12.0/hw/virtio/virtio.c:372
#10 0x0000562dfe2db5ac in virtio_queue_host_notifier_aio_poll (opaque=0x562e02f44168) at /usr/src/debug/qemu-2.12.0/hw/virtio/virtio.c:2423
#11 0x0000562dfe58e83e in run_poll_handlers_once (ctx=ctx@entry=0x562e00c697c0) at util/aio-posix.c:497
#12 0x0000562dfe58f285 in try_poll_mode (blocking=true, ctx=0x562e00c697c0) at util/aio-posix.c:573
#13 aio_poll (ctx=ctx@entry=0x562e00c697c0, blocking=<optimized out>) at util/aio-posix.c:602
#14 0x0000562dfe58c94f in aio_wait_bh_oneshot (ctx=0x562e00c697c0, cb=cb@entry=0x562dfe2cd3e0 <virtio_scsi_dataplane_stop_bh>, opaque=opaque@entry=0x562e02f38170) at util/aio-wait.c:70
#15 0x0000562dfe2cdc9a in virtio_scsi_dataplane_stop (vdev=0x562e02f38170) at /usr/src/debug/qemu-2.12.0/hw/scsi/virtio-scsi-dataplane.c:211
#16 0x0000562dfe455a15 in virtio_bus_stop_ioeventfd (bus=bus@entry=0x562e02f380f8) at hw/virtio/virtio-bus.c:246
#17 0x0000562dfe452e51 in virtio_pci_stop_ioeventfd (proxy=0x562e02f30000) at hw/virtio/virtio-pci.c:294
#18 virtio_pci_common_write (opaque=0x562e02f30000, addr=<optimized out>, val=0, size=<optimized out>) at hw/virtio/virtio-pci.c:1262
#19 0x0000562dfe28d483 in memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, 
    mask=<optimized out>, attrs=...) at /usr/src/debug/qemu-2.12.0/memory.c:530
#20 0x0000562dfe28b199 in access_with_adjusted_size (addr=addr@entry=20, value=value@entry=0x7f4a1e1a4708, size=size@entry=1, access_size_min=<optimized out>, 
    access_size_max=<optimized out>, access_fn=access_fn@entry=0x562dfe28d440 <memory_region_write_accessor>, mr=mr@entry=0x562e02f309d0, attrs=attrs@entry=...)
    at /usr/src/debug/qemu-2.12.0/memory.c:597
#21 0x0000562dfe28f235 in memory_region_dispatch_write (mr=mr@entry=0x562e02f309d0, addr=addr@entry=20, data=0, size=size@entry=1, attrs=attrs@entry=...)
    at /usr/src/debug/qemu-2.12.0/memory.c:1474
#22 0x0000562dfe23f18b in flatview_write_continue (mr=0x562e02f309d0, l=1, addr1=20, len=1, buf=0x7f4a413cf028 <Address 0x7f4a413cf028 out of bounds>, attrs=..., addr=4234149908, 
    fv=0x562e094a9800) at /usr/src/debug/qemu-2.12.0/exec.c:3100
#23 flatview_write (fv=0x562e094a9800, addr=<optimized out>, attrs=..., buf=<optimized out>, len=<optimized out>) at /usr/src/debug/qemu-2.12.0/exec.c:3144
#24 0x0000562dfe242bcf in address_space_write (as=<optimized out>, addr=<optimized out>, attrs=..., buf=<optimized out>, len=<optimized out>) at /usr/src/debug/qemu-2.12.0/exec.c:3260
#25 0x0000562dfe242c75 in address_space_rw (as=<optimized out>, addr=<optimized out>, attrs=..., attrs@entry=..., buf=buf@entry=0x7f4a413cf028 <Address 0x7f4a413cf028 out of bounds>, 
    len=<optimized out>, is_write=<optimized out>) at /usr/src/debug/qemu-2.12.0/exec.c:3271
#26 0x0000562dfe29d758 in kvm_cpu_exec (cpu=cpu@entry=0x562e00f5c000) at /usr/src/debug/qemu-2.12.0/accel/kvm/kvm-all.c:1992
#27 0x0000562dfe27b356 in qemu_kvm_cpu_thread_fn (arg=0x562e00f5c000) at /usr/src/debug/qemu-2.12.0/cpus.c:1215
#28 0x00007f4a2881add5 in start_thread () from /lib64/libpthread.so.0
#29 0x00007f4a28543ead in clone () from /lib64/libc.so.6

Comment 3 yafu 2018-07-03 03:44:26 UTC
The issue also happens when enable iommu for virtio disk:
#virsh edit iommu1
   <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='none' iommu='on' ats='on'/>
      <source file='/home/layer2.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
    </disk>

The backtrace of the qemu process is as follows:
(gdb) bt
#0  0x00007fd8021751b7 in raise () at /lib64/libc.so.6
#1  0x00007fd8021768a8 in abort () at /lib64/libc.so.6
#2  0x000056343de9ed9a in qemu_get_ram_block (addr=<optimized out>) at /usr/src/debug/qemu-2.12.0/exec.c:1115
#3  0x000056343dea2b45 in qemu_map_ram_ptr (ram_block=<optimized out>, addr=140565389668856) at /usr/src/debug/qemu-2.12.0/exec.c:2288
#4  0x000056343dea8ff5 in lduw_le_phys_cached (cache=<optimized out>, cache=<optimized out>, endian=DEVICE_LITTLE_ENDIAN, result=0x0, attrs=..., addr=2)
    at /usr/src/debug/qemu-2.12.0/memory_ldst.inc.c:281
#5  0x000056343dea8ff5 in lduw_le_phys_cached (result=0x0, attrs=..., addr=2, cache=<optimized out>) at /usr/src/debug/qemu-2.12.0/memory_ldst.inc.c:315
#6  0x000056343dea8ff5 in lduw_le_phys_cached (cache=<optimized out>, addr=addr@entry=2) at /usr/src/debug/qemu-2.12.0/memory_ldst.inc.c:334
#7  0x000056343df3c3fc in virtio_queue_empty (vdev=<optimized out>, pa=2, cache=<optimized out>) at /usr/src/debug/qemu-2.12.0/include/hw/virtio/virtio-access.h:166
#8  0x000056343df3c3fc in virtio_queue_empty (vq=0x563442f1a000) at /usr/src/debug/qemu-2.12.0/hw/virtio/virtio.c:228
#9  0x000056343df3c3fc in virtio_queue_empty (vq=0x563442f1a000) at /usr/src/debug/qemu-2.12.0/hw/virtio/virtio.c:372
#10 0x000056343df3c5ac in virtio_queue_host_notifier_aio_poll (opaque=0x563442f1a068) at /usr/src/debug/qemu-2.12.0/hw/virtio/virtio.c:2423
#11 0x000056343e1ef83e in run_poll_handlers_once (ctx=ctx@entry=0x563440a2bb80) at util/aio-posix.c:497
#12 0x000056343e1f0285 in aio_poll (blocking=true, ctx=0x563440a2bb80) at util/aio-posix.c:573
#13 0x000056343e1f0285 in aio_poll (ctx=ctx@entry=0x563440a2bb80, blocking=<optimized out>) at util/aio-posix.c:602
#14 0x000056343e1ed94f in aio_wait_bh_oneshot (ctx=0x563440a2bb80, cb=cb@entry=0x56343df110e0 <virtio_blk_data_plane_stop_bh>, opaque=opaque@entry=0x563442f14580) at util/aio-wait.c:70
#15 0x000056343df11864 in virtio_blk_data_plane_stop (vdev=<optimized out>) at /usr/src/debug/qemu-2.12.0/hw/block/dataplane/virtio-blk.c:283
#16 0x000056343e0b6a15 in virtio_bus_stop_ioeventfd (bus=bus@entry=0x563442f0a0f8) at hw/virtio/virtio-bus.c:246
#17 0x000056343e0b3e51 in virtio_pci_common_write (proxy=0x563442f02000) at hw/virtio/virtio-pci.c:294
#18 0x000056343e0b3e51 in virtio_pci_common_write (opaque=0x563442f02000, addr=<optimized out>, val=0, size=<optimized out>) at hw/virtio/virtio-pci.c:1262
#19 0x000056343deee483 in memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at /usr/src/debug/qemu-2.12.0/memory.c:530
#20 0x000056343deec199 in access_with_adjusted_size (addr=addr@entry=20, value=value@entry=0x7fd7ee1e7488, size=size@entry=1, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=access_fn@entry=0x56343deee440 <memory_region_write_accessor>, mr=mr@entry=0x563442f029d0, attrs=attrs@entry=...) at /usr/src/debug/qemu-2.12.0/memory.c:597
#21 0x000056343def0235 in memory_region_dispatch_write (mr=mr@entry=0x563442f029d0, addr=addr@entry=20, data=0, size=size@entry=1, attrs=attrs@entry=...)
    at /usr/src/debug/qemu-2.12.0/memory.c:1474
#22 0x000056343dea018b in flatview_write (mr=0x563442f029d0, l=1, addr1=20, len=1, buf=0x7fd8089e4028 <Address 0x7fd8089e4028 out of bounds>, attrs=..., addr=4223664148, fv=0x563449c9d6c0) at /usr/src/debug/qemu-2.12.0/exec.c:3100
#23 0x000056343dea018b in flatview_write (fv=0x563449c9d6c0, addr=<optimized out>, attrs=..., buf=<optimized out>, len=<optimized out>) at /usr/src/debug/qemu-2.12.0/exec.c:3144
#24 0x000056343dea3bcf in address_space_write (as=<optimized out>, addr=<optimized out>, attrs=..., buf=<optimized out>, len=<optimized out>) at /usr/src/debug/qemu-2.12.0/exec.c:3260
#25 0x000056343dea3c75 in address_space_rw (as=<optimized out>, addr=<optimized out>, attrs=..., 
    attrs@entry=..., buf=buf@entry=0x7fd8089e4028 <Address 0x7fd8089e4028 out of bounds>, len=<optimized out>, is_write=<optimized out>) at /usr/src/debug/qemu-2.12.0/exec.c:3271
#26 0x000056343defe758 in kvm_cpu_exec (cpu=cpu@entry=0x563440de2000) at /usr/src/debug/qemu-2.12.0/accel/kvm/kvm-all.c:1992
#27 0x000056343dedc356 in qemu_kvm_cpu_thread_fn (arg=0x563440de2000) at /usr/src/debug/qemu-2.12.0/cpus.c:1215
#28 0x00007fd802513dd5 in start_thread () at /lib64/libpthread.so.0
#29 0x00007fd80223daed in clone () at /lib64/libc.so.6

Comment 5 Peter Xu 2018-07-06 08:04:58 UTC
The backtrace looks like the one in Bug 1547940, not sure whether it's a dup.

And I just remembered that Eric Anger just fixed a similar problem too:

commit a99761d3c85679da380c0f597468acd3dc1b53b3
Author: Eric Auger <eric.auger@redhat.com>
Date:   Wed Jun 13 15:19:06 2018 +0200

    exec: Fix MAP_RAM for cached access

Not sure it could fix either (or both) of the problem.

Peter

Comment 6 yafu 2018-07-06 10:59:50 UTC
The bug can not be reproduced with qemu-kvm-rhev-2.10.0-21.el7_5.4.x86_64.

Comment 7 CongLi 2018-07-09 09:53:40 UTC
*** Bug 1599237 has been marked as a duplicate of this bug. ***

Comment 8 yalzhang@redhat.com 2018-07-13 08:34:10 UTC
the issue occur also when start vm with iommu enabled for interface, both for vm using OVMF and seabios

or when attach interface with iommu enabled

libvirt-4.5.0-2.el7.x86_64
qemu-kvm-rhev-2.12.0-7.el7.x86_64

# virsh dumpxml rh | grep /interface  -B6
    <interface type='network'>
      <mac address='52:54:00:b9:54:d4'/>
      <source network='default'/>
      <model type='virtio'/>
      <driver iommu='on' ats='on'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
    </interface>
...
 <iommu model='intel'>
      <driver intremap='on' caching_mode='on' eim='on' iotlb='on'/>
    </iommu>

Comment 9 yalzhang@redhat.com 2018-07-13 08:40:24 UTC
(In reply to yalzhang@redhat.com from comment #8)
> the issue occur also when start vm with iommu enabled for interface, both
> for vm using OVMF and seabios
> 
> or when attach interface with iommu enabled
> 
> libvirt-4.5.0-2.el7.x86_64
> qemu-kvm-rhev-2.12.0-7.el7.x86_64
> 
> # virsh dumpxml rh | grep /interface  -B6
>     <interface type='network'>
>       <mac address='52:54:00:b9:54:d4'/>
>       <source network='default'/>
>       <model type='virtio'/>
>       <driver iommu='on' ats='on'/>
>       <address type='pci' domain='0x0000' bus='0x02' slot='0x00'
> function='0x0'/>
>     </interface>
> ...
>  <iommu model='intel'>
>       <driver intremap='on' caching_mode='on' eim='on' iotlb='on'/>
>     </iommu>

sorry, this issue for interface is already covered in Bug 1520806

Comment 10 Xueqiang Wei 2018-08-27 10:04:28 UTC
Fam,

This is a regression bug, I want to confirm with you if it will be fixed on rhel-7.6 or deferred to later version.


Many thanks

Comment 11 Fam Zheng 2018-09-10 15:04:04 UTC
I agree this is basically bug 1547940, so I'll follow suit and defer to 7.6. But there is some good news: I reproduced the problem with both qemu-kvm-rhev 2.10 and 2.12, but not with upstream. So we can probably identify and backport from upstream to fix the core dump.

However, upstream has a different bug that QEMU hangs when guest kernel is initializing the vIOMMU enabled device. I've sent a series to fix that:

[PATCH 0/2] virtio-scsi: Fix QEMU hang with vIOMMU and ATS
[PATCH 1/2] virtio: Return true from virtio_queue_empty if broken
[PATCH 2/2] virtio-scsi/virtio-blk: Disable poll handlers when stopping vq handler

So maybe this BZ can be used to track those fixes as well.

Comment 12 Fam Zheng 2018-09-10 15:05:01 UTC
I meant "defer to 7.7".

Comment 15 Ademar Reis 2018-12-10 19:59:12 UTC
(In reply to Fam Zheng from comment #11)
> I agree this is basically bug 1547940, so I'll follow suit and defer to 7.6.
> But there is some good news: I reproduced the problem with both
> qemu-kvm-rhev 2.10 and 2.12, but not with upstream. So we can probably
> identify and backport from upstream to fix the core dump.
> 
> However, upstream has a different bug that QEMU hangs when guest kernel is
> initializing the vIOMMU enabled device. I've sent a series to fix that:
> 
> [PATCH 0/2] virtio-scsi: Fix QEMU hang with vIOMMU and ATS
> [PATCH 1/2] virtio: Return true from virtio_queue_empty if broken
> [PATCH 2/2] virtio-scsi/virtio-blk: Disable poll handlers when stopping vq
> handler
> 
> So maybe this BZ can be used to track those fixes as well.

Looks like these patches have not been merged, so we need to follow-up.

Comment 16 John Snow 2019-01-21 23:45:26 UTC
In speaking with Paolo, it seems that we want to commit additional fixes to patch #1 there, but that it can wait for the time being. Patch #2 was ruled incorrect upstream.

Until then, could you please do me a favor and attach the full libvirt XML (or even better, just show me the QEMU CLI?) That will make it easier for me to bisect upstream as I'm a bit new to configuring these devices and I'm running into a spot of trouble doing so.

Thank you,
--js

Comment 17 Xueqiang Wei 2019-01-22 06:53:35 UTC
(In reply to John Snow from comment #16)
> In speaking with Paolo, it seems that we want to commit additional fixes to
> patch #1 there, but that it can wait for the time being. Patch #2 was ruled
> incorrect upstream.
> 
> Until then, could you please do me a favor and attach the full libvirt XML
> (or even better, just show me the QEMU CLI?) That will make it easier for me
> to bisect upstream as I'm a bit new to configuring these devices and I'm
> running into a spot of trouble doing so.
> 
> Thank you,
> --js


Please refer to "External Trackers" above. Polarion test case "RHEL7-11846" added before.

Comment 18 John Snow 2019-01-22 19:19:45 UTC
Apologies for missing it, thank you!

Comment 19 John Snow 2019-01-23 21:07:20 UTC
I found a series of backports from upstream that appear to rectify the issue, but further work appears to be required upstream, which I am not presently prepared to do for the 7.7 timeframe.

That said, If we backport:

1-4: https://lists.gnu.org/archive/html/qemu-devel/2018-04/msg02443.html
5: https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg03567.html
6: https://lists.gnu.org/archive/html/qemu-devel/2018-09/msg03292.html

then the crash and the hang goes away, however, there are some lingering warnings:

qemu-system-x86_64: vtd_iommu_translate: detected translation failure (dev=00:02:00, iova=0x0)
qemu-system-x86_64: New fault is not recorded due to compression of faults
qemu-system-x86_64: virtio: zero sized buffers are not allowed

Since this has been tagged a regression... I am going to lean on the idea that some warnings are better than having it segfault, so I'll prepare a backport and see where the winds blow.

Comment 22 Miroslav Rezanina 2019-02-26 11:24:33 UTC
Fix included in qemu-kvm-rhev-2.12.0-24.el7

Comment 24 Xueqiang Wei 2019-02-28 09:56:39 UTC
Reproduced it on qemu-kvm-rhev-2.12.0-23.el7.  Tested on qemu-kvm-rhev-2.12.0-24.el7, guest boot up successfully and qemu not crashed, but hit other issue in qemu monitor. 


Details as below:

Host:
kernel-3.10.0-1010.el7.x86_64
qemu-kvm-rhev-2.12.0-24.el7

Guest:
kernel-3.10.0-1010.el7.x86_64

1. In host, add "iommu=pt intel_iommu=on" to kernel line, then reboot host

2. Add "intel_iommu=on" to kernel line of q35 guest

3. boot virtio-scsi with iommu_platform=on 
/usr/libexec/qemu-kvm \ 
-M q35,kernel-irqchip=split \
-cpu host \ 
-enable-kvm \ 
-m 2G \ 
-smp 4 \ 
-nodefconfig \ 
-rtc base=localtime,driftfix=slew \ 
-device intel-iommu,device-iotlb=on,intremap \ 
-device virtio-scsi-pci,disable-legacy=on,disable-modern=off,iommu_platform=on,ats=on,id=scsi0,bus=pcie.0 \ 
-drive file=rhel76-64-virtio-scsi.qcow2,if=none,format=qcow2,cache=none,werror=stop,rerror=stop,id=drive-virtio-disk0,aio=native \ 
-device scsi-hd,bus=scsi0.0,drive=drive-virtio-disk0,id=virtio-disk0 \ 
-device piix3-usb-uhci,id=usb \ 
-device usb-tablet,id=tablet0 \ 
-vnc :0 \ 
-k en-us \ 
-vga std \ 
-qmp tcp:0:4444,server,nowait \ 
-boot menu=on \ 
-monitor stdio \ 
-device virtio-net-pci,mac=fa:f7:f8:5f:fa:5b,id=idn0VnaA,vectors=4,netdev=id8xJhp7,bus=pcie.0,addr=06 \ 
-netdev tap,id=id8xJhp7,vhost=on \

4. verify IOMMU enabled, in the guest 
# journalctl -k | grep -i "IOMMU enabled" 
Feb 28 11:13:59 localhost kernel: DMAR: IOMMU enabled
# journalctl -k | grep -i "DMAR: Intel(R) Virtualization Technology for Directed I/O"
Feb 28 11:13:59 localhost kernel: DMAR: Intel(R) Virtualization Technology for Directed I/O


Hit below issue during booting guest.

# sh bug_iommu.sh 
QEMU 2.12.0 monitor - type 'help' for more information
(qemu) qemu-kvm: vtd_iommu_translate: detected translation failure (dev=00:02:00, iova=0x0)
qemu-kvm: New fault is not recorded due to compression of faults
qemu-kvm: virtio: zero sized buffers are not allowed

(qemu) system_reset 
(qemu) qemu-kvm: Guest says index 29281 is available
qemu-kvm: virtio: zero sized buffers are not allowed

(qemu) system_powerdown


If track it by this bug or report a new bug?

Comment 25 John Snow 2019-03-06 20:20:52 UTC
A new bug. It's definitely related, but I believe this requires further work upstream as well and I need to coordinate with Paolo about it, so the timeframe here is different. Thank you!

Comment 26 Xueqiang Wei 2019-03-07 07:35:54 UTC
(In reply to John Snow from comment #25)
> A new bug. It's definitely related, but I believe this requires further work
> upstream as well and I need to coordinate with Paolo about it, so the
> timeframe here is different. Thank you!


Track it by Bug 1686278 - qemu-kvm: vtd_iommu_translate: detected translation failure.

And verify this bug, do you agree with me? Thank you.

Comment 27 John Snow 2019-03-08 19:18:35 UTC
Yes; as long as the VM isn't crashing and works after the warning message, I would say this can be closed for now and we will revisit the spurious warnings in the near future.

Comment 28 Xueqiang Wei 2019-03-11 02:29:14 UTC
According to Comment 24, Comment27,  set status to VERIFIED.

Comment 30 errata-xmlrpc 2019-08-22 09:18:46 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-2019:2553


Note You need to log in before you can comment on or make changes to this bug.