linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Fenghua Yu <fenghua.yu@intel.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Baolu Lu <baolu.lu@linux.intel.com>,
	Vinod Koul <vkoul@kernel.org>,
	"Dave Jiang" <dave.jiang@intel.com>, <dmaengine@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Alistair Popple <apopple@nvidia.com>,
	"Joerg Roedel" <joro@8bytes.org>, Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Lorenzo Stoakes <lstoakes@gmail.com>, <iommu@lists.linux.dev>
Subject: Re: [PATCH v2 08/16] iommu: define and export iommu_access_remote_vm()
Date: Thu, 30 Mar 2023 17:44:27 -0700	[thread overview]
Message-ID: <c4ff442d-706d-bb00-84af-c991454a37de@intel.com> (raw)
In-Reply-To: <ZBhhEK1V+u2oV2Ll@infradead.org>

Hi, Christoph,

On 3/20/23 06:35, Christoph Hellwig wrote:
> On Tue, Mar 07, 2023 at 09:55:28AM -0800, Fenghua Yu wrote:
>>>
>>> I don't quite follow here. Isn't I/O page fault already supported?
>>
>> The following patch 9 in this series explains in details why IDXD device
>> cannot use page fault to write to user memory: https://lore.kernel.org/dmaengine/20230306163138.587484-10-fenghua.yu@intel.com/
>>
>> "DSA supports page fault handling through PRS. However, the DMA engine
>> that's processing the descriptor is blocked until the PRS response is
>> received. Other workqueues sharing the engine are also blocked.
>> Page fault handing by the driver with PRS disabled can be used to
>> mitigate the stalling.
>>
>> With PRS disabled while ATS remain enabled, DSA handles page faults on
>> a completion record by reporting an event in the event log. In this
>> instance, the descriptor is completed and the event log contains the
>> completion record address and the contents of the completion record."
> 
> This seems like a completely broken I/O model, and I don't think Linux
> should support this model when it requires operations like
> access_remote_vm.

This patch set have two parts:
1. Basic event log support and PRS disabling knob.
2. Completion record page fault fixup part. The current patch is the 
major patch in this part. It tries to fix up completion record page 
fault from user space.

Since the fix up in part 2 is debatable and part 1 can be sent out 
independently, how about we send out the parts separately?

In the new part 1, simply warn on completion record page fault and don't 
try to fix it up. Usually a process executes ENQCMD instruction and then 
keeps polling completion record periodically. So the completion record 
will be likely backed by page and won't generate page fault. If page 
fault is really an issue, sysadmin can enable PRS (which is enabled by 
default anyway) and let PRS to handle page fault.

Then in the next step, we will send out a new part 2 to eliminate 
completion record page fault. One proposal is to mmap() kernel allocated 
completion record area. So there won't be completion record page fault 
and fix up(no access_remote_vm() of course).

Is this OK for you?

Thank you very much for your comment!

-Fenghua

  reply	other threads:[~2023-03-31  0:44 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-06 16:31 [PATCH v2 00/16] Enable DSA 2.0 Event Log and completion record faulting features Fenghua Yu
2023-03-06 16:31 ` [PATCH v2 01/16] dmaengine: idxd: make misc interrupt one shot Fenghua Yu
2023-03-06 16:31 ` [PATCH v2 02/16] dmaengine: idxd: add event log size sysfs attribute Fenghua Yu
2023-03-06 16:31 ` [PATCH v2 03/16] dmaengine: idxd: setup event log configuration Fenghua Yu
2023-03-06 16:31 ` [PATCH v2 04/16] dmaengine: idxd: add interrupt handling for event log Fenghua Yu
2023-03-06 16:31 ` [PATCH v2 05/16] dmanegine: idxd: add debugfs for event log dump Fenghua Yu
2023-03-06 16:31 ` [PATCH v2 06/16] dmaengine: idxd: add per DSA wq workqueue for processing cr faults Fenghua Yu
2023-03-06 16:31 ` [PATCH v2 07/16] dmaengine: idxd: create kmem cache for event log fault items Fenghua Yu
2023-03-06 16:31 ` [PATCH v2 08/16] iommu: define and export iommu_access_remote_vm() Fenghua Yu
2023-03-07  1:41   ` Baolu Lu
2023-03-07 17:55     ` Fenghua Yu
2023-03-08  2:23       ` Baolu Lu
2023-03-20 13:35       ` Christoph Hellwig
2023-03-31  0:44         ` Fenghua Yu [this message]
2023-03-07  8:40   ` Jean-Philippe Brucker
2023-03-07 16:33     ` Fenghua Yu
2023-03-11 17:31       ` Fenghua Yu
2023-03-06 16:31 ` [PATCH v2 09/16] dmaengine: idxd: process user page faults for completion record Fenghua Yu
2023-03-06 16:31 ` [PATCH v2 10/16] dmaengine: idxd: add descs_completed field " Fenghua Yu
2023-03-06 16:31 ` [PATCH v2 11/16] dmaengine: idxd: process batch descriptor completion record faults Fenghua Yu
2023-03-06 16:31 ` [PATCH v2 12/16] dmaengine: idxd: add per file user counters for " Fenghua Yu
2023-03-06 16:31 ` [PATCH v2 13/16] dmaengine: idxd: add a device to represent the file opened Fenghua Yu
2023-03-06 16:31 ` [PATCH v2 14/16] dmaengine: idxd: expose fault counters to sysfs Fenghua Yu
2023-03-06 16:31 ` [PATCH v2 15/16] dmaengine: idxd: add pid to exported sysfs attribute for opened file Fenghua Yu
2023-03-06 16:31 ` [PATCH v2 16/16] dmaengine: idxd: add per wq PRS disable Fenghua Yu

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=c4ff442d-706d-bb00-84af-c991454a37de@intel.com \
    --to=fenghua.yu@intel.com \
    --cc=apopple@nvidia.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=dave.jiang@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=hch@infradead.org \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lstoakes@gmail.com \
    --cc=robin.murphy@arm.com \
    --cc=vkoul@kernel.org \
    --cc=will@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;
as well as URLs for NNTP newsgroup(s).