architecture: 0.913
graphic: 0.887
device: 0.840
x86: 0.835
peripherals: 0.821
performance: 0.804
user-level: 0.758
boot: 0.712
semantic: 0.703
debug: 0.700
virtual: 0.699
socket: 0.646
network: 0.643
mistranslation: 0.625
vnc: 0.556
KVM: 0.507
ppc: 0.503
register: 0.503
files: 0.497
PID: 0.475
VMM: 0.458
permissions: 0.407
kernel: 0.367
hypervisor: 0.364
arm: 0.321
assembly: 0.319
i386: 0.268
risc-v: 0.205
TCG: 0.187
--------------------
x86: 0.964
debug: 0.883
hypervisor: 0.807
kernel: 0.609
KVM: 0.158
TCG: 0.125
boot: 0.055
user-level: 0.043
virtual: 0.021
files: 0.013
device: 0.012
PID: 0.012
performance: 0.010
VMM: 0.009
socket: 0.008
architecture: 0.004
graphic: 0.004
network: 0.004
semantic: 0.003
assembly: 0.003
ppc: 0.003
risc-v: 0.003
peripherals: 0.003
vnc: 0.002
register: 0.001
permissions: 0.001
mistranslation: 0.000
arm: 0.000
i386: 0.000

Host system crashes on qemu with DMA remapping

Hy,

the host system crashes completely, when i try to pass an physical device without boot option intel_iommu=on set. In older kernel versions you didn't have to pass that option.

I wonder if this can be easily checked by asking iommu state, avoiding a crash of the complete system.

My data:
cpu model: Intel(R) Core(TM) i7 CPU
qemu version: 2.4.1-r2
kernel version: 4.1.2 x86_64
command line: 
qemu-system-x86_64 -enable-kvm -drive file=/vms/prod/fw/fw.iso,if=virtio,format=raw -drive file=/vms/prod/fw/swap,if=virtio,format=raw -drive file=/vms/prod/fw/fwdata.iso,if=virtio,format=raw -m 512 -nographic -kernel /data/kernels/vmlinuz-2.6.36-gentoo-r8 -append "root=/dev/vda console=ttyS0 earlyprintk=serial" -net nic,model=virtio,macaddr=DE:AD:BE:EF:2D:AD -net tap,ifname=tapfw0,script=/etc/qemu/qemu-ifup -device pci-assign,host=03:00.0

There are also more detailed informations (if needed) here:
https://forums.gentoo.org/viewtopic-p-7923976.html

Thanks,
Antonios.

Sorry, i have to cancel this report.

The problem seems to be somewhere else. After some reboots the same issue came up again.

Triaging old bug tickets ... Can you still reproduce the issue with the latest version of QEMU and the kernel, or could we close this bug nowadays?

[Expired for QEMU because there has been no activity for 60 days.]