Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp4630707ybz; Tue, 28 Apr 2020 15:15:13 -0700 (PDT) X-Google-Smtp-Source: APiQypKn/SGoULVuR4suU7DYahCLJIV63mJ18CT7rbzvO9RYt4YShuPnsqDa9dz3wKIdQZHjIN9c X-Received: by 2002:a17:906:7d7:: with SMTP id m23mr25498466ejc.154.1588112113371; Tue, 28 Apr 2020 15:15:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588112113; cv=none; d=google.com; s=arc-20160816; b=hExvLjqsXWB7OIcjK6FICkc41AhR1CFT311rlXTwQ22WHY/3efttFFWrZckPOU/ZFH tith0O7XZAFa6+MQNBUDAb0xnZ1AQopOS6V6smjVnx9bPvoypmt7NuiGQdd5a05rBKVw GC/T0aKdXABtW84gR61/jiYRYZ5W9KTiMJX2eIdj129u2Qq9DFxgn3rNA3dYDOhdcHzo zfrTqHuhurJlzt19vvdUirZBSoq25dKPfOat6hqWbBCq1ybbjQuuZnEF6x4KHY8kE+sR AV5XmkritAMLJpSuc8xOLSmVyDmWKjUrFofxv3hWWn4y7UvuLJB4MGqWBc8jgcYv3KAZ SM/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:ironport-sdr:ironport-sdr; bh=tlwTgw35DkDdmbwmTqzh5hrSHGgxpCfIs/ROSYx+KJA=; b=Kbf0+QZo1tnbkSWdUfEXaxkT4G15K4ezuRZjG1llMv1mm5sKFGVu5RiQwMhi4shKMh j+TQOsNviq8YtxCd7Ft/GTpkhGjqFT/zGVow8phKiy/jk/awuQ52kaMtnP99ZlddlcEy 3FWkY6sVRKZCrWmEJZ/Ycu2USeJwTkLYUun8+SY6H5qzH81AlTyXOeg+DxLdxAR8HVIc dfdEojz22/YGLhOa2akvgy5Ocdlf5rnjfPSQXtawBOOHlLLxqpZRELxBrNJjrCedMrHs xqchR9aG4F8dyq++mpvaxw1EB3q2wzdAMR52aFUWnUf+GaogqV1V3osMALq9D331qWKW yaWA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bi18si2822418edb.109.2020.04.28.15.14.49; Tue, 28 Apr 2020 15:15:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726355AbgD1WNJ (ORCPT + 99 others); Tue, 28 Apr 2020 18:13:09 -0400 Received: from mga04.intel.com ([192.55.52.120]:57310 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725934AbgD1WNH (ORCPT ); Tue, 28 Apr 2020 18:13:07 -0400 IronPort-SDR: yQx3MJGE+sc0dAYIurwEQ3iq+T/Szvy7Hf2HFY/bIS9Xj0ebglngYztSHuhT0hMcTOaKXWT8Y6 P70wHdtevGTQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Apr 2020 15:13:05 -0700 IronPort-SDR: UrO7djlVD746mQgSPR9NNFNfA6Q93RtblZyn3IyDb/eLZWJ1jt5uCnmYQLA0JuXb00jYhZNGYP TE87jCla70kA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,328,1583222400"; d="scan'208";a="282293855" Received: from jpan9-mobl2.amr.corp.intel.com (HELO localhost) ([10.212.240.17]) by fmsmga004.fm.intel.com with SMTP; 28 Apr 2020 15:13:04 -0700 Date: Tue, 28 Apr 2020 15:13:03 -0700 From: "Jacob Pan (Jun)" To: "Luck, Tony" Cc: Thomas Gleixner , "Yu, Fenghua" , Ingo Molnar , Borislav Petkov , H Peter Anvin , David Woodhouse , Lu Baolu , "Hansen, Dave" , "Raj, Ashok" , "Jiang, Dave" , "Mehta, Sohil" , "Shankar, Ravi V" , linux-kernel , x86 , "iommu@lists.linux-foundation.org" , jacob.jun.pan@intel.com Subject: Re: [PATCH 5/7] x86/mmu: Allocate/free PASID Message-ID: <20200428151303.00004fa2@intel.com> In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F7F608EE2@ORSMSX115.amr.corp.intel.com> References: <1585596788-193989-1-git-send-email-fenghua.yu@intel.com> <1585596788-193989-6-git-send-email-fenghua.yu@intel.com> <87pnbus3du.fsf@nanos.tec.linutronix.de> <20200428112113.000033bd@intel.com> <87tv13o306.fsf@nanos.tec.linutronix.de> <3908561D78D1C84285E8C5FCA982C28F7F608BE9@ORSMSX115.amr.corp.intel.com> <20200428134200.000010f7@intel.com> <3908561D78D1C84285E8C5FCA982C28F7F608EE2@ORSMSX115.amr.corp.intel.com> Organization: intel X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; i686-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 28 Apr 2020 13:59:43 -0700 "Luck, Tony" wrote: > >> So the driver needs to use flush/drain operations to make sure all > >> the in-flight work has completed before releasing/re-using the > >> PASID. > > Are you suggesting we should let driver also hold a reference of the > > PASID? > > The sequence for bare metal is: > > process is queuing requests to DSA > process exits (either deliberately, or crashes, or is killed) > kernel does exit processing > DSA driver is called as part of tear down of "mm" > issues drain/flush commands to ensure that all > queued operations on the PASID for this mm have > completed > PASID can be freed > > There's a 1:1 map from "mm" to PASID ... so reference counting seems > like overkill. Once the kernel is in the "exit" path, we know that no > more work can be queued using this PASID. > There are two users of a PASID, mm and device driver(FD). If either one is not done with the PASID, it cannot be reclaimed. As you mentioned, it could take a long time for the driver to abort. If the abort ends *after* mmdrop, we are in trouble. If driver drops reference after abort/drain PASID is done, then we are safe. > -Tony