All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <joro@8bytes.org>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Neil Horman <nhorman@redhat.com>,
	Neil Horman <nhorman@tuxdriver.com>,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	Chris Wright <chrisw@sous-sol.org>,
	hbabu@us.ibm.com, iommu@lists.linux-foundation.org,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH 1/2] x86/amd-iommu: enable iommu before attaching devices
Date: Sat, 3 Apr 2010 19:38:36 +0200	[thread overview]
Message-ID: <20100403173836.GP24846@8bytes.org> (raw)
In-Reply-To: <20100402155932.GA3516@redhat.com>

On Fri, Apr 02, 2010 at 11:59:32AM -0400, Vivek Goyal wrote:
> 1. kernel crashes, we leave IOMMU enabled.

True for everything except gart and amd iommu.

> 	a. So during this small window when iommu is disabled and we enable
> 	   it back, any inflight DMA will passthrough possibly to an
> 	   unintended physical address as translation is disabled and it
> 	   can corrupt the kdump kenrel.

Right.

> 	b. Even after enabling the iommu, I guess we will continue to
> 	   use cached DTE, and translation information to handle any
> 	   in-flight DMA. The difference is that now iommus are enabled
> 	   so any in-flight DMA should go to the address as intended in
> 	   first kenrel and should not corrupt anything.

Right.

> 
> 3. Once iommus are enabled again, we allocated and initilize protection
>    domains. We attach devices to domains. In the process we flush the
>    DTE, PDE and IO TLBs.
> 
> 	c. Looks like do_attach->set_dte_entry(), by default gives write
> 	   permission (IW) to all the devices. I am assuming that at
> 	   this point of time translation is enabled and possibly unity
> 	   mapped.

No, The IW bit in the DTE must be set because all write permission bits
(DTE and page tabled) are ANDed to determine if a device can write to a
particular address. So as long as the paging mode is unequal to zero the
hardware will walk the page-table first to find out if the device has
write permission. With paging mode == 0 your statement about read-write
unity-mapping is true. This is used for a pass-through domain (iommu=pt)
btw.

	Joerg


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Joerg Roedel <joro@8bytes.org>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Chris Wright <chrisw@sous-sol.org>,
	Neil Horman <nhorman@redhat.com>,
	Neil Horman <nhorman@tuxdriver.com>,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	hbabu@us.ibm.com, iommu@lists.linux-foundation.org,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH 1/2] x86/amd-iommu: enable iommu before attaching devices
Date: Sat, 3 Apr 2010 19:38:36 +0200	[thread overview]
Message-ID: <20100403173836.GP24846@8bytes.org> (raw)
In-Reply-To: <20100402155932.GA3516@redhat.com>

On Fri, Apr 02, 2010 at 11:59:32AM -0400, Vivek Goyal wrote:
> 1. kernel crashes, we leave IOMMU enabled.

True for everything except gart and amd iommu.

> 	a. So during this small window when iommu is disabled and we enable
> 	   it back, any inflight DMA will passthrough possibly to an
> 	   unintended physical address as translation is disabled and it
> 	   can corrupt the kdump kenrel.

Right.

> 	b. Even after enabling the iommu, I guess we will continue to
> 	   use cached DTE, and translation information to handle any
> 	   in-flight DMA. The difference is that now iommus are enabled
> 	   so any in-flight DMA should go to the address as intended in
> 	   first kenrel and should not corrupt anything.

Right.

> 
> 3. Once iommus are enabled again, we allocated and initilize protection
>    domains. We attach devices to domains. In the process we flush the
>    DTE, PDE and IO TLBs.
> 
> 	c. Looks like do_attach->set_dte_entry(), by default gives write
> 	   permission (IW) to all the devices. I am assuming that at
> 	   this point of time translation is enabled and possibly unity
> 	   mapped.

No, The IW bit in the DTE must be set because all write permission bits
(DTE and page tabled) are ANDed to determine if a device can write to a
particular address. So as long as the paging mode is unequal to zero the
hardware will walk the page-table first to find out if the device has
write permission. With paging mode == 0 your statement about read-write
unity-mapping is true. This is used for a pass-through domain (iommu=pt)
btw.

	Joerg


  parent reply	other threads:[~2010-04-03 17:38 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-31 15:24 [PATCH] amd iommu: force flush of iommu prior during shutdown Neil Horman
2010-03-31 15:24 ` Neil Horman
2010-03-31 15:54 ` Vivek Goyal
2010-03-31 15:54   ` Vivek Goyal
2010-03-31 18:28   ` Neil Horman
2010-03-31 18:28     ` Neil Horman
2010-03-31 18:57     ` Eric W. Biederman
2010-03-31 18:57       ` Eric W. Biederman
2010-03-31 19:18       ` Neil Horman
2010-03-31 19:18         ` Neil Horman
2010-03-31 19:51         ` Eric W. Biederman
2010-03-31 19:51           ` Eric W. Biederman
2010-03-31 20:27           ` Neil Horman
2010-03-31 20:27             ` Neil Horman
2010-04-01  4:04             ` Eric W. Biederman
2010-04-01  4:04               ` Eric W. Biederman
2010-04-01 12:49               ` Neil Horman
2010-04-01 12:49                 ` Neil Horman
2010-04-01 14:29             ` Joerg Roedel
2010-04-01 14:29               ` Joerg Roedel
2010-04-01 14:47               ` Neil Horman
2010-04-01 14:47                 ` Neil Horman
2010-04-01 15:56                 ` Joerg Roedel
2010-04-01 15:56                   ` Joerg Roedel
2010-04-01 17:11                   ` Neil Horman
2010-04-01 17:11                     ` Neil Horman
2010-04-01 20:14                     ` Joerg Roedel
2010-04-01 20:14                       ` Joerg Roedel
2010-04-02  0:00                       ` Neil Horman
2010-04-02  0:00                         ` Neil Horman
2010-04-02  0:30                         ` Chris Wright
2010-04-02  0:30                           ` Chris Wright
2010-04-02  1:23                           ` [PATCH 1/2] x86/amd-iommu: enable iommu before attaching devices Chris Wright
2010-04-02  1:23                             ` Chris Wright
2010-04-02  1:31                             ` [PATCH 2/2] x86/amd-iommu: warn when issuing command to uninitiailed cmd buffer Chris Wright
2010-04-02  1:31                               ` Chris Wright
2010-04-02  1:35                             ` [PATCH 1/2] x86/amd-iommu: enable iommu before attaching devices Neil Horman
2010-04-02  1:35                               ` Neil Horman
2010-04-02  1:38                               ` Chris Wright
2010-04-02  1:38                                 ` Chris Wright
2010-04-02  9:11                             ` Joerg Roedel
2010-04-02  9:11                               ` Joerg Roedel
2010-04-02 23:59                               ` Chris Wright
2010-04-02 23:59                                 ` Chris Wright
2010-04-02 15:59                             ` Vivek Goyal
2010-04-02 15:59                               ` Vivek Goyal
2010-04-02 22:38                               ` Chris Wright
2010-04-02 22:38                                 ` Chris Wright
2010-04-02 22:55                                 ` Eric W. Biederman
2010-04-02 22:55                                   ` Eric W. Biederman
2010-04-02 23:57                                   ` Chris Wright
2010-04-02 23:57                                     ` Chris Wright
2010-04-03 17:38                               ` Joerg Roedel [this message]
2010-04-03 17:38                                 ` Joerg Roedel
2010-04-05 14:17                                 ` Vivek Goyal
2010-04-05 14:17                                   ` Vivek Goyal
2010-04-05 14:32                                   ` Joerg Roedel
2010-04-05 14:32                                     ` Joerg Roedel
2010-04-05 15:34                             ` Neil Horman
2010-04-05 15:34                               ` Neil Horman
2010-03-31 18:43   ` [PATCH] amd iommu: force flush of iommu prior during shutdown Eric W. Biederman
2010-03-31 18:43     ` Eric W. Biederman
2010-03-31 21:25 ` Chris Wright
2010-03-31 21:25   ` Chris Wright
2010-04-01  1:13   ` Neil Horman
2010-04-01  1:13     ` Neil Horman
2010-04-01  1:39     ` Chris Wright
2010-04-01  1:39       ` Chris Wright
2010-04-01  2:24     ` Vivek Goyal
2010-04-01  2:24       ` Vivek Goyal
2010-04-01 12:53       ` Neil Horman
2010-04-01 12:53         ` Neil Horman
2010-04-01 15:02         ` Vivek Goyal
2010-04-01 15:02           ` Vivek Goyal
2010-04-01 15:13           ` Neil Horman
2010-04-01 15:13             ` Neil Horman
2010-04-01  2:44   ` Vivek Goyal
2010-04-01  2:44     ` Vivek Goyal
2010-04-01  7:10     ` Chris Wright
2010-04-01  7:10       ` Chris Wright
2010-04-01 12:56       ` Neil Horman
2010-04-01 12:56         ` Neil Horman

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=20100403173836.GP24846@8bytes.org \
    --to=joro@8bytes.org \
    --cc=chrisw@sous-sol.org \
    --cc=ebiederm@xmission.com \
    --cc=hbabu@us.ibm.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nhorman@redhat.com \
    --cc=nhorman@tuxdriver.com \
    --cc=vgoyal@redhat.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.