Hi, On 1/17/24 10:15 AM, pet...@redhat.com wrote: > From: Peter Xu <pet...@redhat.com> > > There're issue reported that when syetem_reset the VM with an intel iommu > device and MT2892 PF(mlx5_core driver), the host kernel throws DMAR error. > > https://issues.redhat.com/browse/RHEL-7188 > > Alex quickly spot a possible issue on ordering of device resets. > > It's verified by our QE team then that it is indeed the root cause of the > problem. Consider when vIOMMU is reset before a VFIO device in a system > reset: the device can be doing DMAs even if the vIOMMU is gone; in this > specific context it means the shadow mapping can already be completely > destroyed. Host will see these DMAs as malicious and report. > > To fix it, we'll need to make sure all devices under the vIOMMU device > hierachy will be reset before the vIOMMU itself. There's plenty of trick > inside, one can get those by reading the last patch.
I have a case with intel iommu and vhost-net where I see that the vIOMMU gets disabled by the guest before vhost_dev_stop() causing some spurious lookup failures. This happens when rebooting the guest (see [PATCH] hw/virtio/vhost: Disable IOTLB callbacks when IOMMU gets disabled <https://lore.kernel.org/all/20250120173339.865681-1-eric.au...@redhat.com/> https://lore.kernel.org/all/20250120173339.865681-1-eric.au...@redhat.com/ for more context). I observe that 1) the guest disables the IOMMU through the vtd_handle_gcmd_write 2) vtd_reset (initiated from qemu_system_reset) 3) vhost_dev_stop (initiated from qemu_system_reset) So I can effectively see the viommu is reset before vhost-net stop. 2) is already an issue that looks the same as the one addressed in this series. Now I am also in trouble wrt 1). I don't know yet which chain of events causes the VTD GCMD TE bit to be written but this would also cause spurious vhost IOLTB misses. I haven't seen any follow-up on this series. Is anyone still looking at this issue? Peter gave some guidance about the way to rework the reset chain. Is it still up to date? Thanks Eric > > I didn't check other vIOMMUs, but this series should fix the issue for VT-d > as of now. The solution can be slightly ugly, but a beautiful one can be > very non-trivial. > > Review comments welcomed, thanks. > > Peter Xu (4): > reset: qemu_register_reset_one() > reset: Allow multiple stages of system resets > intel_iommu: Tear down address spaces before IOMMU reset > intel_iommu: Reset vIOMMU at the last stage of system reset > > include/sysemu/reset.h | 5 ++++ > hw/core/reset.c | 67 ++++++++++++++++++++++++++++++------------ > hw/i386/intel_iommu.c | 56 +++++++++++++++++++++++++++++++++-- > 3 files changed, 107 insertions(+), 21 deletions(-) >
