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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id EEECDC6FA82 for ; Wed, 21 Sep 2022 17:11:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4F1A4940007; Wed, 21 Sep 2022 13:11:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4A2116B0075; Wed, 21 Sep 2022 13:11:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 36962940007; Wed, 21 Sep 2022 13:11:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 272966B0074 for ; Wed, 21 Sep 2022 13:11:52 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id DA4EB807E1 for ; Wed, 21 Sep 2022 17:11:51 +0000 (UTC) X-FDA: 79936734822.09.64F6AD0 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by imf22.hostedemail.com (Postfix) with ESMTP id 21758C001A for ; Wed, 21 Sep 2022 17:11:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663780311; x=1695316311; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=DiEGsbtLgITtlM9yaoGvIKChT6L0JZ2Jt6gnaU2GdQM=; b=PYHtrMltEHpWfy2uF+/5kY8+b0//AhzxUjjvz6dm/ASEECSdtP9fmtkB sn6icNKpPooHg+G3hVuWyoTI+yXQ+mIBYvbyATf9OXHFLoeS5cB4epcWJ tgT3m3eby+qCIw1BFR3Lq34TGybIazuk1g72vR488q1HnYtRwMpUoKB27 zZMmo+L5QASfGBFwVLF2jZZGUmxxuWxMb0wuWjtbgTyLjQbjxac/dSb6f d/Btl9cCZDZz3UdYi9uF1fZ/tMenecG3SSvNo4tx/2Kl80RbAuRuZv7eY nr8+6x2gXus/19Fxj5k3j6kuS4wehhhA+qVF/mJirwqX5VAvpJLwaGybu g==; X-IronPort-AV: E=McAfee;i="6500,9779,10477"; a="279791383" X-IronPort-AV: E=Sophos;i="5.93,333,1654585200"; d="scan'208";a="279791383" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Sep 2022 10:11:49 -0700 X-IronPort-AV: E=Sophos;i="5.93,333,1654585200"; d="scan'208";a="948240024" Received: from nchaplot-mobl1.amr.corp.intel.com (HELO [10.209.89.231]) ([10.209.89.231]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Sep 2022 10:11:47 -0700 Message-ID: Date: Wed, 21 Sep 2022 10:11:46 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCHv8 00/11] Linear Address Masking enabling Content-Language: en-US To: Ashok Raj Cc: "Kirill A. Shutemov" , Jacob Pan , "Kirill A. Shutemov" , Ashok Raj , Dave Hansen , Andy Lutomirski , Peter Zijlstra , x86@kernel.org, Kostya Serebryany , Andrey Ryabinin , Andrey Konovalov , Alexander Potapenko , Taras Madan , Dmitry Vyukov , "H . J . Lu" , Andi Kleen , Rick Edgecombe , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Jason Gunthorpe , Joerg Roedel References: <20220912224930.ukakmmwumchyacqc@box.shutemov.name> <20220914144518.46rhhyh7zmxieozs@box.shutemov.name> <20220914151818.uupzpyd333qnnmlt@box.shutemov.name> <20220914154532.mmxfsr7eadgnxt3s@box.shutemov.name> <20220914165116.24f82d74@jacob-builder> <20220915090135.fpeokbokkdljv7rw@box.shutemov.name> <20220915172858.pl62a5w3m5binxrk@box.shutemov.name> <562dec4d-a39f-b517-58a3-45f691a2d10a@intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1663780311; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=wtNI2O6AEp61Y9QSjvF5kNuOpZDHyAZw7efBnc860A8=; b=8VpBtI8PTZWvyUYkBoR3jWxv8kDPMm/xh3IB80/afz5LE06PrUaCj3LBTCw9AUY44Za/aK Z1lNNOSvJnIZJjT43jte3TafTBdDKZgtpZzdpUYB946P+FW29ohcRlyUPdqiHkolL0s79g 9IWAZNxB700Ma0kUDj5k24F6BfvmMfo= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=PYHtrMlt; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf22.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.136 as permitted sender) smtp.mailfrom=dave.hansen@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663780311; a=rsa-sha256; cv=none; b=Ar2v0F8R0WRRTbKvU08jtqDZ+HwKcz9fY1av9RQOkB3UHttQvV2zzFvv/n7sP4Je6phs3C 1MaVN3KL3Tt2XzwX1ThSLG0gCGcysLFaaxg33JRcOQKf2e3bJpU9Rz9iIfOlS0eGLZQUH0 KQ/Qr+keuGH3cATbgdAYDXuyk7hXxj4= X-Rspam-User: X-Stat-Signature: zmsabns6o1ekg4uw4zffxb9ds5pd55tq X-Rspamd-Queue-Id: 21758C001A Authentication-Results: imf22.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=PYHtrMlt; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf22.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.136 as permitted sender) smtp.mailfrom=dave.hansen@intel.com X-Rspamd-Server: rspam08 X-HE-Tag: 1663780310-7449 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 9/21/22 10:08, Ashok Raj wrote: > On Wed, Sep 21, 2022 at 09:57:47AM -0700, Dave Hansen wrote: >> On 9/15/22 10:28, Kirill A. Shutemov wrote:> + /* Serialize against >> address tagging enabling * >>> + if (mmap_write_lock_killable(mm)) >>> + return -EINTR; >>> + >>> + if (!arch_can_alloc_pasid(mm)) { >>> + mmap_write_unlock(mm); >>> + return -EBUSY; >>> + } >> Shouldn't this actually be some kind of *device* check? > The device will enable svm only when its capable of it, and performs all > the normal capability checks like PASID, ATS etc before enabling it. > This is the final step before the mm is hooked up with the IOMMU. What does that mean, though? Are you saying that any device compatibility with an mm is solely determined by the IOMMU in play, so the IOMMU code should host the mm compatibility checks?