On Fri, Sep 07, 2018 at 10:46:40AM +0800, Peter Xu wrote: > QEMU is not handling the global DMAR switch well, especially when from > "on" to "off". > > Let's first take the example of system reset. > > Assuming that a guest has IOMMU enabled. When it reboots, we will drop > all the existing DMAR mappings to handle the system reset, however we'll > still keep the existing memory layouts which has the IOMMU memory region > enabled. So after the reboot and before the kernel reloads again, there > will be no mapping at all for the host device. That's problematic since > any software (for example, SeaBIOS) that runs earlier than the kernel > after the reboot will assume the IOMMU is disabled, so any DMA from the > software will fail. > > For example, a guest that boots on an assigned NVMe device might fail to > find the boot device after a system reboot/reset and we'll be able to > observe SeaBIOS errors if we capture the debugging log: > > WARNING - Timeout at nvme_wait:144! > > Meanwhile, we should see DMAR errors on the host of that NVMe device. > It's the DMA fault that caused a NVMe driver timeout. > > The correct fix should be that we do proper switching of device DMA > address spaces when system resets, which will setup correct memory > regions and notify the backend of the devices. This might not affect > much on non-assigned devices since QEMU VT-d emulation will assume a > default passthrough mapping if DMAR is not enabled in the GCMD > register (please refer to vtd_iommu_translate). However that's required > for an assigned devices, since that'll rebuild the correct GPA to HPA > mapping that is needed for any DMA operation during guest bootstrap. > > Besides the system reset, we have some other places that might change > the global DMAR status and we'd better do the same thing there. For > example, when we change the state of GCMD register, or the DMAR root > pointer. Do the same refresh for all these places. > > Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1625173 > CC: QEMU Stable <qemu-sta...@nongnu.org> > Reported-by: Cong Li <c...@redhat.com> > Signed-off-by: Peter Xu <pet...@redhat.com>
Ping? Regards, -- Peter Xu
