qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v7 0/5] IOMMU: intel_iommu support map and unmap


From: Peter Xu
Subject: Re: [Qemu-devel] [PATCH v7 0/5] IOMMU: intel_iommu support map and unmap notifications
Date: Thu, 8 Dec 2016 10:39:53 +0800
User-agent: Mutt/1.5.24 (2015-08-30)

On Wed, Dec 07, 2016 at 10:04:57PM +0800, Lan Tianyu wrote:

[...]

> >Even if the context entry is cleared and invalidated, IMHO it does not
> >mean that we should be using GPA address space, nor do we need to put
> >it into guest physical address space. Instead, it simply means this
> >device cannot do any IO at that time. If IO comes, IOMMU should do
> >fault reporting to guest OS, which should be treated as error.
> 
> Yes, that looks right and there will be fault event reported by pIOMMU
> if context entry is no present for DMA untranslated request. This goes back
> to the first gap to report pIOMMU fault event to vIOMMU.

Right.

> 
> For disabling via clearing DMA translation via gcmd.TE bit, assigned
> device should work after clearing operation and it's still necessary to
> restore GPA->HPA mapping since we can't assume guest won't clear the bit
> after enabling DMA translation.
> 
> This maybe low priority gap since Linux IOMMU driver don't disable DMA
> translation frequently or dynamically. But we also should consider the
> situation.

I see. That's something I missed indeed. Yes we should support
disabling via gcmd.te. Also, looks like we still don't support
passthrough mode translation as well. That's something we need too
since that means we don't supporting iommu=pt.

I agree with you that we can postpone these tasks temporarily, just
like the error handling you mentioned.

> 
> >
> >So I think we are emulating the correct guest behavior here - we don't
> >need to do anything if a device is detached from an existing IOMMU
> >domain in guest. If we do (e.g., we replay the GPA address space on
> >that device when it is detached, so the shadow page table for that
> >device maps the whole guest memory), that is dangerous, because with
> >that the device can DMA to anywhere it wants to guest memory.
> 
> If guest want to disabling DMA translation, this is expected behavior
> and device model should follow guest configuration. This just likes most
> distributions don't enable VTD DMA translation by default and it's OS
> choice.

My previous comment only suites the case when a device is moved
outside an IOMMU domain. I agree with you on the rest.

Btw, do you have time to help review my RFC series for "vt-d replay"?
:) I'd like to receive any further review comments besides the issues
mentioned above since IMHO they can be seperated from current series,
I have noted them down in my pending list.

(I think I need to test iommu=pt a bit more to make sure it works
 asap)

Thanks,

-- peterx



reply via email to

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