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;
Date:   Wed, 21 Sep 2022 10:08:42 -0700
From:   Ashok Raj <ashok.raj@intel.com>
To:     Dave Hansen <dave.hansen@intel.com>
CC:     "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Jacob Pan <jacob.jun.pan@intel.com>,
        "Kirill A. Shutemov" <kirill@shutemov.name>,
        Ashok Raj <ashok_raj@linux.intel.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Andy Lutomirski <luto@kernel.org>,
        "Peter Zijlstra" <peterz@infradead.org>, <x86@kernel.org>,
        Kostya Serebryany <kcc@google.com>,
        Andrey Ryabinin <ryabinin.a.a@gmail.com>,
        Andrey Konovalov <andreyknvl@gmail.com>,
        Alexander Potapenko <glider@google.com>,
        "Taras Madan" <tarasmadan@google.com>,
        Dmitry Vyukov <dvyukov@google.com>,
        "H . J . Lu" <hjl.tools@gmail.com>,
        Andi Kleen <ak@linux.intel.com>,
        Rick Edgecombe <rick.p.edgecombe@intel.com>,
        <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
        Jason Gunthorpe <jgg@nvidia.com>,
        "Joerg Roedel" <joro@8bytes.org>, Ashok Raj <ashok.raj@intel.com>
Subject: Re: [PATCHv8 00/11] Linear Address Masking enabling
Message-ID: <YytFGqv5V4T8lbM8@araj-MOBL2.amr.corp.intel.com>
References: <20220912224930.ukakmmwumchyacqc@box.shutemov.name>
 <20220914144518.46rhhyh7zmxieozs@box.shutemov.name>
 <YyHvF2K7ELVSTGvB@araj-MOBL2.amr.corp.intel.com>
 <20220914151818.uupzpyd333qnnmlt@box.shutemov.name>
 <YyHz7H0uyqG58b3E@araj-MOBL2.amr.corp.intel.com>
 <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>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <562dec4d-a39f-b517-58a3-45f691a2d10a@intel.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?Pe1BC2tRc4/sJmF6IrAZCrZw71BcSJQFdyXj6mm3LWYJbBddc/H/zk1YpmiY?=
 =?us-ascii?Q?nS0lBYAdvkRo6peTbdkAWVhaVSEGYLHwDlQgGeWKJVIbCq/8qF9iYXknTJwD?=
 =?us-ascii?Q?6FGSZOMlUaeWqW5j7XiYp/ZLRrs3C3n2ysxUPDhr82gmDE/P6EGOKTyBW2cG?=
 =?us-ascii?Q?KwrKPh1gIBVahpFzGzkCe6VP7H4oLQJ/RrHNvssa2mJYxU04fl6gFeJSttz2?=
 =?us-ascii?Q?Ul9KA5EFCEynadp/qc5LhhLb4KYnjRPWiuASaxVa0elabhFgclrWiZTQ9mn6?=
 =?us-ascii?Q?ZiZ/sjsxHaB5ePwhk1ZIDU2+7AL0GEdaCHRzJR0Np2NybKEX96DV5enhNXzP?=
 =?us-ascii?Q?hjS897rFphxdMXDTZJlieU5OYnbGRmaOTPwkNhHeikq1osrBw4sMcRUUMECb?=
 =?us-ascii?Q?W9EsKN2MLe1Bp2T4xckuXqZH4YHRKZOj5GoxtM6A5EFwvFE6XXgIX8BH8TUg?=
 =?us-ascii?Q?TH7GmfC3DNX3qsiAEGqPCrVK2m4bfVBA7X/p/Rx+KU884/cqB0tNEJXqILnP?=
 =?us-ascii?Q?nYUWSQVx2rOD7b583JIMXUv09whdS0AVE/EBa15EUtO8fTr/CcGie0KLCahs?=
 =?us-ascii?Q?eaFVM81jz5MNpn1E8Mz420+oByy5Ivu6MIZtGMGOdZQJAZS4RDdicfu/gYOi?=
 =?us-ascii?Q?r36OXxv1sDcQU/nOO/mVhhhK4csHq6mw3YJZs0zbWeVOFfbG4fhO3hzXRmqn?=
 =?us-ascii?Q?jNyv2neXJZ5VCZroLAC+4o5bWjimq+dXjfRnqxG9eH8rzOfCsBNy8fj39EM+?=
 =?us-ascii?Q?tkieGy/5wccRVGOQJ7I6/2Rp2smNf14TWpaXX3MkmZGRZa9fhcwuYWqAZEpD?=
 =?us-ascii?Q?uAaNFn3Mad3VMEd8kTFN37QRUdhJevOYBi01QerCcM3YAGm88KWiihurZajP?=
 =?us-ascii?Q?Lzplu8H+7PRk6nd2r1SR/HWW0OCyK6MpdMKE/vwGZDcVMnubn355TRl+LplW?=
 =?us-ascii?Q?bII3Zl9379X3bGZKfni+Xj2PNNsS7GVEbVJE9H5IXz144LQpHRe9r5PdHT1V?=
 =?us-ascii?Q?zpMEMcVhyFxuHl9d6eqqh+4zPcrcv9wUY59qM2J0yAuItG94LE0idXoJXUh5?=
 =?us-ascii?Q?3kPTmuKsHg3OO3puwZW4dgO36Jq4u2zHBvm4FmAwFXWV9qxLANif7m3bcNPv?=
 =?us-ascii?Q?c+/e90UDafaEIpaDXhaexYFqk1Z9zj4iAqzIWfKqW6O69prLLh509lmvL+dt?=
 =?us-ascii?Q?Qkj2wsQXxxkyN0idMXkekS8rdCXas7lK2jqqSJnQ2jPv4ranrrxDcFCi3hXg?=
 =?us-ascii?Q?Lg59zr+TWGIBwDZ2wht1VFxDvnR6dFQae3Hrt9g6SJ2GFW0FNkvIBl+bXj+Y?=
 =?us-ascii?Q?wPK65IdcxxWfhWf1EnDGCuMtO88YlBZ60ngpluSU89IQUBWQGt2KoBRMde6F?=
 =?us-ascii?Q?LOT/DSmKy3mF7YLi99VvvPN+G/auo2QCOsECM8Bvuuojt8PiBjslT30C8GJX?=
 =?us-ascii?Q?wVAf7qP6G0jPszNvBdSd5lz+eqPudyq9BSt6QbXg+UTrHGdOIixG0UxHpxkr?=
 =?us-ascii?Q?QfF61ReXhNiPOQPtbQrx3sc8GOoknKyQFG6cyMQMgr34z+8pHYbEYvOZVlwM?=
 =?us-ascii?Q?t06xjuy6SpAu7gn53F4VO6MsJVLqzhrMxc0TnfCm?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 40cc6dfb-ae2f-4305-488c-08da9bf3f21c
X-MS-Exchange-CrossTenant-AuthSource: SJ1PR11MB6201.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2022 17:08:46.9375
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: wq/RSNEckzp0PahMCg6kyX3jga+tQWh+sG42EJf20GJ/3T98rVUjgrFcsVJ6wyf18H4LM6i7n2xJv4ntDU7uOQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4920
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE
        autolearn=ham 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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.

> 
> The question here is whether the gunk in the mm's address space is
> compatible with the device.
> 
>  * Can the device walk the page tables in use under the mm?
>  * Does the device interpret addresses the same way as the CPUs
>    using the mm?
> 
> The page table format is, right now, wholly determined at boot at the
> latest.  But, it probably wouldn't hurt to pretend like it _might_
> change at runtime.
> 
> The address interpretation part is, of course, what LAM changes.  It's
> also arguable that it includes features like protection keys.  I can
> totally see a case where folks might want to be careful and disallow
> device access to an mm where pkeys are in use.