linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Oded Gabbay <oded.gabbay@gmail.com>
Cc: Jerome Glisse <j.glisse@gmail.com>,
	lsf-pc@lists.linux-foundation.org,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Joerg Roedel <joro@8bytes.org>
Subject: Re: [LSF/MM ATTEND] HMM (heterogeneous memory manager) and GPU
Date: Wed, 03 Feb 2016 11:41:50 +0000	[thread overview]
Message-ID: <1454499710.4788.176.camel@infradead.org> (raw)
In-Reply-To: <1454499350.4788.170.camel@infradead.org>

[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]

On Wed, 2016-02-03 at 11:35 +0000, David Woodhouse wrote:
> 
> In the ideal case, there's no need for the device driver to get
> involved at all. When a page isn't found in the page tables, the IOMMU
> code calls handle_mm_fault() and either populates the page and sends a
> a 'success' response, or sends an 'invalid fault' response back.

I missed a bit here; I should have made it explicit:

The device hardware receives that page-request response, successful or
otherwise, and is supposed to act on it accordingly. The device's own
request then fails, and it should have some coherent way of reporting
that to the device driver.

The point is that there should be no need to 'short-circuit' that and
pass notification directly from the IOMMU code to the device driver
that "there was a fault on PASID x". That direct notification hack
doesn't even *tell* us which device-side context was affected, if
there's more than one context accessing a given PASID.

(Actually, in the Intel case for integrated devices, there *are* some
opaque¹ bits in the page-request which do include that information. But
that's horrid, and not a solution for the general case.)

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation


¹ to the IOMMU code.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

  reply	other threads:[~2016-02-03 11:41 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-28 17:55 [LSF/MM ATTEND] HMM (heterogeneous memory manager) and GPU Jerome Glisse
2016-01-29  9:50 ` Kirill A. Shutemov
2016-01-29 13:35   ` Jerome Glisse
2016-02-01 15:46 ` Aneesh Kumar K.V
2016-02-02 23:03   ` Jerome Glisse
2016-02-03  0:40 ` David Woodhouse
2016-02-03  8:13   ` Oded Gabbay
2016-02-03  8:40     ` David Woodhouse
2016-02-03  9:21       ` Oded Gabbay
2016-02-03 10:15         ` David Woodhouse
2016-02-03 11:01           ` Oded Gabbay
2016-02-03 11:07             ` Oded Gabbay
2016-02-03 11:35               ` David Woodhouse
2016-02-03 11:41                 ` David Woodhouse [this message]
2016-02-03 11:41                 ` Oded Gabbay
2016-02-03 12:22                   ` David Woodhouse
2016-02-25 13:49   ` Joerg Roedel

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=1454499710.4788.176.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=j.glisse@gmail.com \
    --cc=joro@8bytes.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=oded.gabbay@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).