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 997C4C43334 for ; Thu, 14 Jul 2022 18:12:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0112D9401B4; Thu, 14 Jul 2022 14:12:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F03619401A5; Thu, 14 Jul 2022 14:12:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DCAEF9401B4; Thu, 14 Jul 2022 14:12:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id CAEE79401A5 for ; Thu, 14 Jul 2022 14:12:56 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id C32C6214FA for ; Thu, 14 Jul 2022 18:12:55 +0000 (UTC) X-FDA: 79686501510.18.7134977 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by imf22.hostedemail.com (Postfix) with ESMTP id C3353C007E for ; Thu, 14 Jul 2022 18:12:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1657822374; x=1689358374; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=AZbSgw4PiPhHiI2IkamjWGYAFK+m9rBc4mek9Q/SNdQ=; b=EMIs67z44Y4MobzwRDlXlQIMLMgNxNMb8WThPJ6ipZJMRF3Bfisvi31Q 05nK89SoUmQn+V8VKKSEZHwBjNT9b6XPrPBcSUqCJ3uvrIpDY1vcyv9kJ 1pzdWllW3+5ACaozoAR9j9GI5WYhPPHyQFKvHMCDAMRIi4/xbiPelUd5f IfArqyri25eRGE1wOTWqmDgZdaasPlj6J1DWYUIrOVWW9O+21IKfP/Xsd TLxNY+bqAtS9NAPsm/zetVZMDfESVGcjmoM76e7OVM/KfhdPjLRqcVxYw c8TEDqUZm7KzKIURD1cuW28qufqVaWJSzy4gkK21ggqIBvJWQfi/buNdw g==; X-IronPort-AV: E=McAfee;i="6400,9594,10408"; a="349563099" X-IronPort-AV: E=Sophos;i="5.92,272,1650956400"; d="scan'208";a="349563099" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jul 2022 11:12:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.92,272,1650956400"; d="scan'208";a="923180403" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga005.fm.intel.com with ESMTP; 14 Jul 2022 11:12:48 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 2917FF1; Thu, 14 Jul 2022 21:12:55 +0300 (EEST) Date: Thu, 14 Jul 2022 21:12:55 +0300 From: "Kirill A. Shutemov" To: Alexander Potapenko Cc: Dave Hansen , Andy Lutomirski , Peter Zijlstra , the arch/x86 maintainers , Kostya Serebryany , Andrey Ryabinin , Andrey Konovalov , Dmitry Vyukov , "H . J . Lu" , Andi Kleen , Rick Edgecombe , Linux Memory Management List , LKML Subject: Re: [PATCHv4 6/8] x86/mm: Provide ARCH_GET_UNTAG_MASK and ARCH_ENABLE_TAGGED_ADDR Message-ID: <20220714181255.7aonbyzca3avfylp@black.fi.intel.com> References: <20220622162230.83474-1-kirill.shutemov@linux.intel.com> <20220622162230.83474-7-kirill.shutemov@linux.intel.com> <20220712171445.74b46mgdxgaub3qj@black.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=EMIs67z4; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf22.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 134.134.136.100) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657822375; a=rsa-sha256; cv=none; b=Y+MBTaJCnuKt3wfSQCvljhLST0GpW4iC+wc8eamfejaQljflSOcr+2uEHaKONSU58TJHgj 1TtY92y+kd/BRA3+eTixFLkVntPLB9h94SwvY3kN1iuqRcQk8L2gR59JdzKZ0hsD9aSAu7 PgmTGrlZyLv0QBF3SPtmkkopUUu5Cv4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657822375; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=AE6hDs7j39NfJl3WDUhqfmadupGdpdKn4LGZM1pL5FI=; b=3ukogIdg3I9cAKZGEfIUt61SH5knI65jfICTTN+RoAkH9rWpBhmU6mw5Je7CjI1lSVSo0M A4ja2fnlaLrFKtvcdJt7keQ0KCOG0USkX0jn2VHFSziyBt3lwDlD7LbpThezHK6LUEHsAZ yC2BJfnRaIvuBwC9vEzXRTEbEfR8P0o= Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=EMIs67z4; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf22.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 134.134.136.100) smtp.mailfrom=kirill.shutemov@linux.intel.com X-Rspam-User: X-Stat-Signature: ffueu89hkmxi6i65ghb133cngj3p7z8n X-Rspamd-Queue-Id: C3353C007E X-Rspamd-Server: rspam03 X-HE-Tag: 1657822374-604713 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 Thu, Jul 14, 2022 at 04:28:36PM +0200, Alexander Potapenko wrote: > On Tue, Jul 12, 2022 at 7:14 PM Kirill A. Shutemov > wrote: > > > > On Tue, Jul 12, 2022 at 03:12:01PM +0200, Alexander Potapenko wrote: > > > On Wed, Jun 22, 2022 at 6:22 PM Kirill A. Shutemov > > > wrote: > > > > > > > > Add a couple of arch_prctl() handles: > > > > > > > > - ARCH_ENABLE_TAGGED_ADDR enabled LAM. The argument is required number > > > > of tag bits. It is rounded up to the nearest LAM mode that can > > > > provide it. For now only LAM_U57 is supported, with 6 tag bits. > > > > > > > > - ARCH_GET_UNTAG_MASK returns untag mask. It can indicates where tag > > > > bits located in the address. > > > > > > > Am I right that the desired way to detect the presence of LAM without > > > enabling it is to check that arch_prctl(ARCH_GET_UNTAG_MASK, ...) > > > returns zero? > > > > Returns -1UL, but yes. > > No, I meant the return value of arch_prctl(), but in fact neither > seems to be true. > > Right now e.g. for the 5.17 kernel arch_prctl(ARCH_GET_UNTAG_MASK, > &bits) returns -EINVAL regardless of the underlying hardware. > A new kernel with your patches will return 0 and set bits=-1UL on both > non-LAM and LAM-enabled machines. How can we distinguish those? With CPUID? -- Kirill A. Shutemov