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 429FEC433EF for ; Thu, 12 May 2022 17:04:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 71F006B0075; Thu, 12 May 2022 13:03:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6CD3C6B0078; Thu, 12 May 2022 13:03:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5945D8D0001; Thu, 12 May 2022 13:03:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 4A4016B0075 for ; Thu, 12 May 2022 13:03:59 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1ADF2312F0 for ; Thu, 12 May 2022 17:03:59 +0000 (UTC) X-FDA: 79457713398.17.B34EBF3 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by imf07.hostedemail.com (Postfix) with ESMTP id 9703B400AD for ; Thu, 12 May 2022 17:03:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1652375036; x=1683911036; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=sMZBofsExJ4XZ0XAXWwsuHVeTzHqA51EM19kzKk8154=; b=kU6JeGx246fzPsWdpaaJK7gJPkcxTWnYPQvevK9308E6L925/aOAAfuv SxO30yFULw9PjnKd42HQhJGlZaiolMaXwHd1bFVBZ85MzjAtfozevNBe8 BX5PsjjV9OqXMzE8qrH3JzgJ+I09SxiWVxUCpjpDqN8H9NG+BIIAqt5cV ZZ0uXdA5V/FAUKgA9Njl4T2hQ/DzMej8bwV6KLRX4/UTQzgS6cGoO35rW GxkjpBFnqYxQnUEg7TsRUapulzk8fYnNxR5tRSljVfYklfDw/+TmRQGU8 1YsKswjiDYc09VrS/9rTbzOdyiqCvI6Sg3n84++3kPGmS4wyh9rUvrxHN A==; X-IronPort-AV: E=McAfee;i="6400,9594,10345"; a="356491799" X-IronPort-AV: E=Sophos;i="5.91,220,1647327600"; d="scan'208";a="356491799" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 May 2022 10:00:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.91,220,1647327600"; d="scan'208";a="712002221" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga001.fm.intel.com with ESMTP; 12 May 2022 10:00:02 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id C4A29CE; Thu, 12 May 2022 20:00:01 +0300 (EEST) Date: Thu, 12 May 2022 20:00:01 +0300 From: "Kirill A. Shutemov" To: David Laight Cc: Dave Hansen , Andy Lutomirski , Peter Zijlstra , "x86@kernel.org" , Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , "H . J . Lu" , Andi Kleen , Rick Edgecombe , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] x86: Implement Linear Address Masking support Message-ID: <20220512170001.6olwffikg4u3cke3@black.fi.intel.com> References: <20220511022751.65540-1-kirill.shutemov@linux.intel.com> <20220511022751.65540-2-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 9703B400AD X-Stat-Signature: kawmfw1bddue4jsknu944gahe7hfduxx Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=kU6JeGx2; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf07.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.43) smtp.mailfrom=kirill.shutemov@linux.intel.com X-Rspam-User: X-HE-Tag: 1652375029-905149 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, May 12, 2022 at 01:01:07PM +0000, David Laight wrote: > From: Kirill A. Shutemov > > Sent: 11 May 2022 03:28 > > > > Linear Address Masking feature makes CPU ignore some bits of the virtual > > address. These bits can be used to encode metadata. > > > > The feature is enumerated with CPUID.(EAX=07H, ECX=01H):EAX.LAM[bit 26]. > > > > CR3.LAM_U57[bit 62] allows to encode 6 bits of metadata in bits 62:57 of > > user pointers. > > > > CR3.LAM_U48[bit 61] allows to encode 15 bits of metadata in bits 62:48 > > of user pointers. > > > > CR4.LAM_SUP[bit 28] allows to encode metadata of supervisor pointers. > > If 5-level paging is in use, 6 bits of metadata can be encoded in 62:57. > > For 4-level paging, 15 bits of metadata can be encoded in bits 62:48. > > > ... > > +static vaddr clean_addr(CPUArchState *env, vaddr addr) > > +{ > > + CPUClass *cc = CPU_GET_CLASS(env_cpu(env)); > > + > > + if (cc->tcg_ops->do_clean_addr) { > > + addr = cc->tcg_ops->do_clean_addr(env_cpu(env), addr); > > The performance of a conditional indirect call will be horrid. > Over-engineered when there is only one possible function. It is QEMU patch. As I mentioned in the cover letter, it was rejected by upstream, but it is functional and can be used for testing before HW arrived. I may give it another try when I get time to look deeper at TCG. -- Kirill A. Shutemov