[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-stable] [PATCH v3] intel_iommu: better handling of dmar state
From: |
Peter Xu |
Subject: |
Re: [Qemu-stable] [PATCH v3] intel_iommu: better handling of dmar state switch |
Date: |
Fri, 28 Sep 2018 13:23:48 +0800 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
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 <address@hidden>
> Reported-by: Cong Li <address@hidden>
> Signed-off-by: Peter Xu <address@hidden>
Ping?
Regards,
--
Peter Xu