Received: by 2002:a05:6602:2086:0:0:0:0 with SMTP id a6csp4387729ioa; Wed, 27 Apr 2022 02:42:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyEgegu2GyfAathyufP44ZxlOiWlEWgC3u5p7LtajS0CE2St56am81y2tRfBebDC88nxziH X-Received: by 2002:a65:5a8e:0:b0:365:3b6:47fb with SMTP id c14-20020a655a8e000000b0036503b647fbmr23377351pgt.147.1651052558528; Wed, 27 Apr 2022 02:42:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651052558; cv=none; d=google.com; s=arc-20160816; b=kxSPXyltqLc7gL9gQ9tzwVCVSJYKkQheGycMj5QnSs/fAkeaGx2dwH4FZ9Z4MklKmb 8UTfvlPAx4ciuez/D3v7JKK2Pw9m0M3hap3S20k6iGJX2U2iSWS64DBmXF1+XxQk4Cy+ XqqjQpPlUBdnONshRhTxM4aV/tCUD1/v0Gu2b3Di+nCdct25Ya77gIwKetoMiSVsyXGR mEwFzDMNK6+HNttUZYppLlpiRtiucEY2J0ooHzape/eu948XVMllLdErfQXnouKn41o3 tlZrzakMjGN5bTJk/NQTxkm+CGBewcrV40t9TVogo0D5xPWwy1WmNGRXeijjYgvXgFKO 2jYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=6ROZqpJuB/HbbZhPA/Eb/dv26rKQksoXCioPe/ki04o=; b=rY4dLvdwotvAPdXUg1H3GmklC+D2G6E3imk19+1EYTsCnW5Pea/TeQeVlCXj6v9Ir2 y49TcBEukSTQFaw4Ob7+bkHcOXP8WwUibB8osRE8JKK0MXc/xNz1BmzPIqKBUU0SkLaG 2GUQ9NwZyR40FxjYQCtQtDoVCp8AlHSfHGMXZU+9faEFYOFiWhkU4KPP2JLY5DX9eM/k NJfRgcJxifD6cR4uBd5LAWCdCnidYsiKAVyklIaY1adBwDutujU4FKHQJ+tgzC9hFsA6 oH/fz/P8nBFRfcOQkWDGVvpLMP57ZvLSAUS41XNrWz80k32YEhOTAxbV42HqWRsCeuRg CEdA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=jc1eENzL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id p2-20020a1709026b8200b00153b2d16510si985909plk.280.2022.04.27.02.42.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Apr 2022 02:42:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=jc1eENzL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 9CF8614A52A; Wed, 27 Apr 2022 02:17:44 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347837AbiDZP1s (ORCPT + 99 others); Tue, 26 Apr 2022 11:27:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34500 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239155AbiDZP1r (ORCPT ); Tue, 26 Apr 2022 11:27:47 -0400 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6E3F321E33 for ; Tue, 26 Apr 2022 08:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650986679; x=1682522679; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=uHUL5BJ27oyqSRllLdSrhqSu1/tdYAnraNE1Llkso44=; b=jc1eENzLC93X6YMWJcXoC66p3WfE7xLD7NwP99nCZ9cQcIM35sqGgROh 8y5PpVSTyOUmfoBz1D/YM07x5nCaACtvIG5eH6MxnK8FSRsWKNa+IVfXM XC8fNWWH/e6aGeTgeygkA1t6b8LiRgjlaDVZFTXWC3DZU4TOXytTOwyhO yHODt0xyZDkRI6Xx5ss/xKNOYCfnGz8zPyWFhM1dd1ylgvGZwCMOyhfZu +ZFks/Hjygfa2vUKzI7/ztFAof3u9bobiEPacKtZg3ggL2x2KQf0+6qAW lPrQY+t47l3rzI/OX/ZEltVx5wriCMfevkCXKohtTahrSrOhaX10U2kNg w==; X-IronPort-AV: E=McAfee;i="6400,9594,10328"; a="265134782" X-IronPort-AV: E=Sophos;i="5.90,291,1643702400"; d="scan'208";a="265134782" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2022 08:24:23 -0700 X-IronPort-AV: E=Sophos;i="5.90,291,1643702400"; d="scan'208";a="595808700" Received: from dsocek-mobl2.amr.corp.intel.com (HELO [10.212.69.119]) ([10.212.69.119]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2022 08:24:22 -0700 Message-ID: <8c044e49-74bb-df56-8a60-663013c0910e@intel.com> Date: Tue, 26 Apr 2022 08:27:00 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH v4 05/11] iommu/sva: Assign a PASID to mm on PASID allocation and free it on mm exit Content-Language: en-US To: Jean-Philippe Brucker Cc: "zhangfei.gao@foxmail.com" , Fenghua Yu , Joerg Roedel , Ravi V Shankar , Tony Luck , Ashok Raj , Peter Zijlstra , Dave Hansen , x86 , linux-kernel , iommu , Ingo Molnar , Borislav Petkov , Andy Lutomirski , Josh Poimboeuf , Thomas Gleixner , will@kernel.org, robin.murphy@arm.com, zhangfei.gao@linaro.org References: <76ec6342-0d7c-7c7b-c132-2892e4048fa1@intel.com> <22b659c7-e972-7a56-2bd7-8df3b4820d4e@intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/25/22 09:40, Jean-Philippe Brucker wrote: > The problem is that we'd have to request the device driver to stop DMA > before we can destroy the context and free the PASID. We did consider > doing this in the release() MMU notifier, but there were concerns about > blocking mmput() for too long (for example > https://lore.kernel.org/linux-iommu/4d68da96-0ad5-b412-5987-2f7a6aa796c3@amd.com/ > though I think there was a more recent discussion). We also need to drain > the PRI and fault queues to get rid of all references to that PASID. Is the concern truly about blocking mmput() itself? Or, is it about releasing the resources associated with the mm?