Bug 1662270 - Boot guest with device assignment+vIOMMU, qemu prompts "vtd_interrupt_remap_msi: MSI address low 32 bit invalid: 0x0" when first rebooting guest
Summary: Boot guest with device assignment+vIOMMU, qemu prompts "vtd_interrupt_remap_...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux Advanced Virtualization
Classification: Red Hat
Component: qemu-kvm
Version: 8.1
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: 8.1
Assignee: Peter Xu
QA Contact: Pei Zhang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-12-27 09:19 UTC by Pei Zhang
Modified: 2020-02-03 04:41 UTC (History)
8 users (show)

Fixed In Version: qemu-kvm-4.0.0-3.module+el8.1.0+3265+26c4ed71
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-06 07:12:13 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:3723 0 None None None 2019-11-06 07:12:37 UTC

Description Pei Zhang 2018-12-27 09:19:33 UTC
Description of problem:
Boot guest with device assignment+vIOMMU, then reboot guest, qemu will prompt "qemu-kvm: vtd_interrupt_remap_msi: MSI address low 32 bit invalid: 0x0".


Version-Release number of selected component (if applicable):
qemu-kvm-3.1.0-2.module+el8+2606+2c716ad7.x86_64
4.18.0-57.el8.x86_64


How reproducible:
100%


Steps to Reproduce:
1. Boot qemu, see[1]

2. In guest, reboot, qemu terminal will prompt invalid message.
# reboot

(qemu) qemu-kvm: vtd_interrupt_remap_msi: MSI address low 32 bit invalid: 0x0

Actual results:
qemu prompts invalid message when first reboot guest.


Expected results:
qemu should not prompts invalid message.


Additional info:
1. Without vIOMMU, everything works well.

Reference:
[1]
/usr/libexec/qemu-kvm -name rhel8.0 \
-M q35,kernel-irqchip=split \
-cpu Haswell-noTSX -m 8G \
-device intel-iommu,intremap=true,caching-mode=true \
-smp 4,sockets=1,cores=4,threads=1 \
-device pcie-root-port,id=root.1,chassis=1 \
-device pcie-root-port,id=root.2,chassis=2 \
-device pcie-root-port,id=root.3,chassis=3 \
-device pcie-root-port,id=root.4,chassis=4 \
-blockdev driver=file,cache.direct=off,cache.no-flush=on,filename=/home/rhel8.0.qcow2,node-name=my_file \
-blockdev driver=qcow2,node-name=my,file=my_file \
-device virtio-blk-pci,drive=my,id=virtio-blk0,bus=root.1 \
-netdev tap,id=hostnet0,vhost=on \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=18:66:da:5f:dd:02,bus=root.2,iommu_platform=on,ats=on \
-vnc :2 \
-monitor stdio \
-device vfio-pci,host=0000:3b:00.0,bus=root.3 \
-device vfio-pci,host=0000:3b:00.1,bus=root.4 \

Comment 1 Pei Zhang 2018-12-27 09:26:03 UTC
Additional info:
Slow train bug: Bug 1662272

Comment 2 Pei Zhang 2018-12-27 10:22:18 UTC
Additional info:
3. 

Host kernel line:
# cat /proc/cmdline 
BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-57.el8.x86_64 root=/dev/mapper/rhel_dell--per730--29-root ro crashkernel=auto resume=/dev/mapper/rhel_dell--per730--29-swap rd.lvm.lv=rhel_dell-per730-29/root rd.lvm.lv=rhel_dell-per730-29/swap console=ttyS0,115200n81 intel_iommu=on

Guest kernel line:
# cat /proc/cmdline 
BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-57.el8.x86_64 root=/dev/mapper/rhel_bootp--73--227--122-root ro console=tty0 console=ttyS0,115200n8 biosdevname=0 crashkernel=auto resume=/dev/mapper/rhel_bootp--73--227--122-swap rd.lvm.lv=rhel_bootp-73-227-122/root rd.lvm.lv=rhel_bootp-73-227-122/swap

Comment 10 Pei Zhang 2019-06-12 07:24:54 UTC
Verified with qemu-kvm-4.0.0-3.module+el8.1.0+3265+26c4ed71.x86_64:

Boot/Reboot/Shutdown guest with vIOMMU and device assignment, qemu keeps working well. 

So this bug has been fixed very well. Move to 'VERIFIED'.

Comment 12 errata-xmlrpc 2019-11-06 07:12:13 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/RHBA-2019:3723


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