Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp266623pxb; Mon, 7 Feb 2022 10:47:21 -0800 (PST) X-Google-Smtp-Source: ABdhPJypNFDduJtTcTtGgSGGz7Wp0lR5PuJlbsp9BGadq8o++9NmsHEIUEXezsf6sgVHm+49Q+pu X-Received: by 2002:a63:8849:: with SMTP id l70mr583842pgd.560.1644259641253; Mon, 07 Feb 2022 10:47:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644259641; cv=none; d=google.com; s=arc-20160816; b=lRl7QcN9EZrMSiNPPlItrFm1JX57PtnORbhqzUvOeRTR2Sq3k4QOHo7AGI319DOHSv 5s0HO3CecmBXEcuhI3XxdMVehaT+D45XOS6Cq+TZzniYN6Ug9rJf9GWVYkimaQPPtvyy NFBEJ+sG2SJJHTWmMebJbOHVdCiCtiCYvGM6MMQi/3Aqj9oOqwDFp/Ez+DcM1FMArnx/ 3aa4CtHQrCd17Q6FOwnbb8LYbghGC0pothKKEE+UwRmVEeV/PcH9m2mHHEu7mkouzOJA tOmFyRxxjwdJNa/gDdu/GQCf8+g0L+QycMcn9lG03w8vH003rvqibxtQgFZ9Zhzz0+tE OETg== 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:to:content-language:subject:cc:user-agent:mime-version :date:message-id:dkim-signature; bh=E2V5XgaIsCytN5K6WMA/fYJrULVPA77sjLP0zbefIF0=; b=exyw4h/wPrd4BQoW8q1PiAsFGREzlEXtGdAR4lWDMhiWyJrLXtZXcUp0Mm82GJ/oxi DrCCk4K37Om52dpcRnAbSqk0US9eZOlNUxP9ZtrsHIXjUBdzVEH0t71Iigx6n7W0QlQg w8BgkqKTxyLD0RCUZB0rl3kRk/gmG7ZDJqZYbBIwftL+qWqavv7j7GB/6LggOmJkqntr 1FVLbooTJxzqlu63ezln1CAQyNkF/tQlvxR3kYDeX5SUsqVfp0CYD9GHXNtZgkwyR5qP ClPwoRJKd4nicaE1Iqas66j/P3mGGxVxesx9sG5LjUKX6sJuBk5R3CT2REvrp+REKJxW Kf1Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=cjvYk7Nn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w14si10759767plg.101.2022.02.07.10.47.08; Mon, 07 Feb 2022 10:47:21 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=cjvYk7Nn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355921AbiBEHMK (ORCPT + 99 others); Sat, 5 Feb 2022 02:12:10 -0500 Received: from mga18.intel.com ([134.134.136.126]:42996 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229835AbiBEHMJ (ORCPT ); Sat, 5 Feb 2022 02:12:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1644045129; x=1675581129; h=message-id:date:mime-version:cc:subject:to:references: from:in-reply-to:content-transfer-encoding; bh=qHvqdITzBAglMG363Se0HM+YGOVHexjxQRvG2eU8Hto=; b=cjvYk7Nnnge49ut0WcgI1bhUZiJSq71XQYlL6jXxC+g/xihzJEK+dm3c 8s1iVOfdnsc34MFRMXkSMTcM1nFm9vc5dOev2ChRXyV3C33oa4ndqDN8Y XJ4rxNGh+XbMBoFOM1yFio2kCkVaasLH+WVaEU/qqJ+p7nnmRRaC31oLB RpzNrWPIXqG5ALT5jv1rssgx/m4PgEUmlOID9y+PqoP5HhlsMasnKp0eJ GURuZwZemYNnLdT9PI4j569/FqOeziWNDB6thV9/A53YHV/5R8duIvgCW 6U+IiYC9DqDuPKQ7A4/FTDCDniEgSLdaYvY1s4qJNGw6hYB/2a3k/KHZs Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10248"; a="232061189" X-IronPort-AV: E=Sophos;i="5.88,345,1635231600"; d="scan'208";a="232061189" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Feb 2022 23:12:08 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,345,1635231600"; d="scan'208";a="677304617" Received: from allen-box.sh.intel.com (HELO [10.239.159.118]) ([10.239.159.118]) by fmsmga001.fm.intel.com with ESMTP; 04 Feb 2022 23:12:04 -0800 Message-ID: <01fee139-873c-347c-b8e4-f6af52dca168@linux.intel.com> Date: Sat, 5 Feb 2022 15:10:57 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Cc: baolu.lu@linux.intel.com, Thomas Gleixner , Dave Hansen , Ingo Molnar , Borislav Petkov , Peter Zijlstra , Andy Lutomirski , Tony Luck , Joerg Roedel , Josh Poimboeuf , Jacob Pan , Ashok Raj , Ravi V Shankar , iommu@lists.linux-foundation.org, x86 , linux-kernel Subject: Re: [PATCH v3 05/11] iommu/sva: Assign a PASID to mm on PASID allocation and free it on mm exit Content-Language: en-US To: Fenghua Yu References: <20220128202905.2274672-1-fenghua.yu@intel.com> <20220128202905.2274672-6-fenghua.yu@intel.com> <6ace7131-4671-6956-944f-df01e5d63470@linux.intel.com> From: Lu Baolu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/5/22 1:10 PM, Fenghua Yu wrote: > Hi, Baolu, > On Sat, Feb 05, 2022 at 11:50:59AM +0800, Lu Baolu wrote: >> Hi Fenghua, >> >> On 2022/1/29 4:28, Fenghua Yu wrote: >>> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c >>> index 92fea3fbbb11..ef03b2176bbd 100644 >>> --- a/drivers/iommu/intel/iommu.c >>> +++ b/drivers/iommu/intel/iommu.c >>> @@ -4781,7 +4781,7 @@ static int aux_domain_add_dev(struct dmar_domain *domain, >>> link_failed: >>> spin_unlock_irqrestore(&device_domain_lock, flags); >>> if (list_empty(&domain->subdevices) && domain->default_pasid > 0) >>> - ioasid_put(domain->default_pasid); >>> + ioasid_free(domain->default_pasid); >>> return ret; >>> } >>> @@ -4811,7 +4811,7 @@ static void aux_domain_remove_dev(struct dmar_domain *domain, >>> spin_unlock_irqrestore(&device_domain_lock, flags); >>> if (list_empty(&domain->subdevices) && domain->default_pasid > 0) >>> - ioasid_put(domain->default_pasid); >>> + ioasid_free(domain->default_pasid); >>> } >>> static int prepare_domain_attach_device(struct iommu_domain *domain, >> >> The domain->default_pasid is not relevant to SVA and it's being cleaned >> up by another series. No need to take care of it in this series. > > Because ioasid_put() is renamed to ioasid_free() in this patch, without > above changes, this series cannot be compiled. > > Thomas and I discussed how to handle aux_domain while you will remove > the entire aux_domain code (https://lore.kernel.org/lkml/87zgnf29op.ffs@tglx/). > The above changes are minimal and temporary changes to compile this series. > The changes will be removed along with the entire aux_domain by your > removing aux_domain series later in 5.18. Okay. Make sense to me. Best regards, baolu