All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Lan Tianyu <tianyu.lan@intel.com>
Cc: "Aviv B.D" <bd.aviv@gmail.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	"Liu, Yi L" <yi.l.liu@intel.com>,
	"Wu, Fengguang" <fengguang.wu@intel.com>
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	[thread overview]
Message-ID: <20161208023849.GF28693@pxdev.xzpeter.org> (raw)
In-Reply-To: <c1f4b99f-1bfd-9742-b8ca-360fa6fa609c@intel.com>

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	other threads:[~2016-12-08  2:40 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-28 15:51 [Qemu-devel] [PATCH v7 0/5] IOMMU: intel_iommu support map and unmap notifications Aviv B.D
2016-11-28 15:51 ` [Qemu-devel] [PATCH v7 1/5] IOMMU: add option to enable VTD_CAP_CM to vIOMMU capility exposoed to guest Aviv B.D
2016-12-01  4:25   ` Tian, Kevin
2016-11-28 15:51 ` [Qemu-devel] [PATCH v7 2/5] IOMMU: change iommu_op->translate's is_write to flags, add support to NO_FAIL flag mode Aviv B.D
2016-11-28 15:51 ` [Qemu-devel] [PATCH v7 3/5] IOMMU: enable intel_iommu map and unmap notifiers Aviv B.D
2016-11-29  3:23   ` 蓝天宇
2016-11-29  7:57     ` Aviv B.D.
2016-11-28 15:51 ` [Qemu-devel] [PATCH v7 4/5] IOMMU: add specific replay function with default implemenation Aviv B.D
2016-11-28 15:51 ` [Qemu-devel] [PATCH v7 5/5] IOMMU: add specific null implementation of iommu_replay to intel_iommu Aviv B.D
2016-11-28 16:36   ` Alex Williamson
2016-11-28 18:57     ` Aviv B.D.
2016-11-30  9:23 ` [Qemu-devel] [PATCH v7 0/5] IOMMU: intel_iommu support map and unmap notifications Peter Xu
2016-12-01  4:21   ` Tian, Kevin
2016-12-01  8:13     ` Lan Tianyu
2016-12-02  5:59     ` Peter Xu
2016-12-02  6:23       ` Tian, Kevin
2016-12-02  6:58         ` Peter Xu
2016-12-02 17:26       ` Alex Williamson
2016-12-01  8:27   ` Lan Tianyu
2016-12-02  6:08     ` Peter Xu
2016-12-02 17:30       ` Alex Williamson
2016-12-06  2:03         ` Lan, Tianyu
2016-12-06  2:18         ` Peter Xu
2016-12-01 15:42   ` Alex Williamson
2016-12-02  6:17     ` Peter Xu
2016-12-01  3:26 ` Tian, Kevin
2016-12-01  6:44 ` Lan Tianyu
2016-12-02  6:52   ` Peter Xu
2016-12-06  6:30     ` Lan Tianyu
2016-12-06  6:51       ` Peter Xu
2016-12-06  7:06         ` Lan Tianyu
2016-12-06  7:22           ` Peter Xu
2016-12-06  8:27             ` Lan Tianyu
2016-12-06 10:59               ` Peter Xu
2016-12-06 16:58                 ` Alex Williamson
2016-12-07  6:09                 ` Lan Tianyu
2016-12-07  6:43                   ` Peter Xu
2016-12-07 14:04                     ` Lan Tianyu
2016-12-08  2:39                       ` Peter Xu [this message]
2016-12-08  5:41                         ` Lan Tianyu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161208023849.GF28693@pxdev.xzpeter.org \
    --to=peterx@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=bd.aviv@gmail.com \
    --cc=fengguang.wu@intel.com \
    --cc=jan.kiszka@siemens.com \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=tianyu.lan@intel.com \
    --cc=yi.l.liu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.