From: Matthew Wilcox <willy@infradead.org>
To: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com>
Cc: linux-mm@kvack.org, linux-pci@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: Question regarding page fault handlers in kernel mappings
Date: Mon, 4 Jan 2021 16:56:28 +0000 [thread overview]
Message-ID: <20210104165628.GB22407@casper.infradead.org> (raw)
In-Reply-To: <d511840d-50af-44bd-92db-876180c503a5@amd.com>
On Mon, Jan 04, 2021 at 11:38:38AM -0500, Andrey Grodzovsky wrote:
> Hello, I am AMD developer and I am trying to implement support for on the
> fly graceful graphic card extraction.
Are you talking about surprise removal (eg card on the other end of
a Thunderbolt connector where there is no possibility for software
locking), or are you talking about an orderly removal (where the user
requests removal and there is time to tear everything down gracefully)?
> One issue I am facing is how to avoid
> accesses to physical addresses both in RAM and MMIO from user mode and
> kernel after device is gone. For user accesses (mmap) I use the page fault
> handler to route all RW accesses to dummy zero page. I would like to do the
> same for kernel side mappings both form RAM (kmap) and device IO
> (ioremap) but it looks like there is no same mechanism of page fault
> handlers for kernel side mappings.
ioremap() is done through the vmalloc space. It would, in theory, be
possible to reprogram the page tables used for vmalloc to point to your
magic page. I don't think we have such a mechanism today, and there are
lots of problems with things like TLB flushes. It's probably going to
be harder than you think.
I'm adding the linux-pci mailing list so you can be helped with the
logistics of device hot-remove.
next prev parent reply other threads:[~2021-01-04 16:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-04 16:38 Andrey Grodzovsky
2021-01-04 16:56 ` Matthew Wilcox [this message]
2021-01-04 20:00 ` Andrey Grodzovsky
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=20210104165628.GB22407@casper.infradead.org \
--to=willy@infradead.org \
--cc=Andrey.Grodzovsky@amd.com \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.org \
--cc=linux-pci@vger.kernel.org \
/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