qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3] intel_iommu: better handling of dmar state s


From: Peter Xu
Subject: Re: [Qemu-devel] [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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]