From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D5C26C433E0 for ; Mon, 4 Jan 2021 16:56:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0B3FF224DE for ; Mon, 4 Jan 2021 16:56:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0B3FF224DE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6CEC16B00A1; Mon, 4 Jan 2021 11:56:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 680C16B00A2; Mon, 4 Jan 2021 11:56:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 56EE48D001C; Mon, 4 Jan 2021 11:56:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0158.hostedemail.com [216.40.44.158]) by kanga.kvack.org (Postfix) with ESMTP id 45A0F6B00A1 for ; Mon, 4 Jan 2021 11:56:46 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 04CBB181AC9B6 for ; Mon, 4 Jan 2021 16:56:46 +0000 (UTC) X-FDA: 77668696812.27.toes82_140d67d274d1 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id D43CB3D668 for ; Mon, 4 Jan 2021 16:56:45 +0000 (UTC) X-HE-Tag: toes82_140d67d274d1 X-Filterd-Recvd-Size: 2935 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Mon, 4 Jan 2021 16:56:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=CsdkWqMPYpLCdzLV15LOrVfBBoHeF9cMJDrzd73YqOc=; b=oQxmBpr8U0onNaYXpyVK8tNb+Z kt5/aJPVRz98uFxNHYffECmzK13HNGUfsWAvygVZ3/qI/mTJNjyQM8payfCXv9TLlqGRs9VuT95vc l2bQwMOOvWU+jTh1LStrj6A4GPU9+yZtk3YZjxULjgRxMuGeJcfYYfjZD6A96lgZMEQRCiOFkOnkl Vzgu+u9Ban3DLI84mYN1Am6G1KafWbfvYrdNkVE7YRCbWJ85+ql1E8Ewaa6CB1eglOEyo3gYqzfL0 qN5ZJvtwFCxOKul8epnK9hYHOm0vt9K0o6nGaQ/4UWDjb6EIoKJdL47BoU2MrEcgQFCF7BKn1ZQ1f N67AWKUA==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1kwT9g-000KLt-B5; Mon, 04 Jan 2021 16:56:32 +0000 Date: Mon, 4 Jan 2021 16:56:28 +0000 From: Matthew Wilcox To: Andrey Grodzovsky Cc: linux-mm@kvack.org, linux-pci@vger.kernel.org, Andrew Morton Subject: Re: Question regarding page fault handlers in kernel mappings Message-ID: <20210104165628.GB22407@casper.infradead.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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.