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 0C44FC7115B for ; Mon, 23 Jun 2025 12:41:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8F6216B00B6; Mon, 23 Jun 2025 08:41:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8A6706B00B7; Mon, 23 Jun 2025 08:41:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7948D6B00B9; Mon, 23 Jun 2025 08:41:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 63C7C6B00B6 for ; Mon, 23 Jun 2025 08:41:54 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 674561A021B for ; Mon, 23 Jun 2025 12:41:53 +0000 (UTC) X-FDA: 83586627306.24.1693134 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) by imf20.hostedemail.com (Postfix) with ESMTP id 8959A1C0002 for ; Mon, 23 Jun 2025 12:41:50 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=KRzNWOQh; spf=none (imf20.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.198.163.15) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750682511; 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=U0o14DGiJnSi7vVKhAAHMEvd0sjiE7mXGak9h1Hk8lo=; b=j0Ojh9w2bpRPLOzEZHK9z7vwaSiEm2hVQchbss6Q/IaCppAJyYL6W3vhvgktQAQljGi8+k EW/Glj1S2L7M5ZCGKmbwA6azSujrEwgwVo0YbzWl8m0ifP8P1z344FPi97UmLog5Fv23kI xemFivtOKvhWskGBgomYDM2sloy+yUs= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=KRzNWOQh; spf=none (imf20.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.198.163.15) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750682511; a=rsa-sha256; cv=none; b=gXEBhtzS8gFDAOY2YlLHFCbXUfeyHcKnyRyPz5dDw50SwSOn2uK/6FpeSbvkqULVVO9G6y r34+sl9ZmeUXkPb7XZPxLKuu6LsgE+Ha4RhROt7e6WS/stqKNuF0M5QA6rRW5X8SSStYj0 UTT3BrupG6fTq+QQ1hEZFvf4bPJhMqs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1750682510; x=1782218510; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=K3UZr1v5ln6fJSE0bzWb9sF553xHwQWW1kwtTJIV7Kk=; b=KRzNWOQhSEurWJJfg8/AyLuPUpo7kQy66nzQ8pi96vPwbgDexZkjKBPZ YUAICoswIP3jWwrsikSX/c8aUoJMdnoXjLLE1qa4sJs9jJQ5Bb01VydGk vrzalkIqRtmjR12itozSlBcabteaGSyCQZlBsVBjTG660MgRqPorWAsVl AlUSctuzkVg2vCZLmMHSoW9UzmfWVDy+ieI/fWLoYrBlLL8p81LwF0oYS hAMbvIhBF6eVfJjQLT20l836N6e7+SEMnsI15VywKWgvvLwCrzOrzecv9 VnR4Fl6eGoKtlZujp9Rxqm6tJvZSPMaXRbUR1ja+roXvhDnk/E6jrab6v g==; X-CSE-ConnectionGUID: v0VXjWoLQEmB1s9YCrKkoA== X-CSE-MsgGUID: NDM5H+jXRk6FX7ALJrCU9w== X-IronPort-AV: E=McAfee;i="6800,10657,11473"; a="53026770" X-IronPort-AV: E=Sophos;i="6.16,258,1744095600"; d="scan'208";a="53026770" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jun 2025 05:41:48 -0700 X-CSE-ConnectionGUID: 10Ymcep+Q3up0gnu1kePHQ== X-CSE-MsgGUID: I55PCHToQRCNtiihmEgd6A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,258,1744095600"; d="scan'208";a="151738727" Received: from black.fi.intel.com ([10.237.72.28]) by fmviesa006.fm.intel.com with ESMTP; 23 Jun 2025 05:41:32 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id D7895126; Mon, 23 Jun 2025 15:41:30 +0300 (EEST) Date: Mon, 23 Jun 2025 15:41:30 +0300 From: "Kirill A. Shutemov" To: Dave Hansen Cc: Andrew Cooper , acme@redhat.com, aik@amd.com, akpm@linux-foundation.org, alexander.shishkin@linux.intel.com, ardb@kernel.org, ast@kernel.org, bp@alien8.de, brijesh.singh@amd.com, changbin.du@huawei.com, christophe.leroy@csgroup.eu, corbet@lwn.net, daniel.sneddon@linux.intel.com, dave.hansen@linux.intel.com, ebiggers@google.com, geert+renesas@glider.be, houtao1@huawei.com, hpa@zytor.com, jgg@ziepe.ca, jgross@suse.com, jpoimboe@kernel.org, kai.huang@intel.com, kees@kernel.org, leitao@debian.org, linux-doc@vger.kernel.org, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux@rasmusvillemoes.dk, luto@kernel.org, mcgrof@kernel.org, mhiramat@kernel.org, michael.roth@amd.com, mingo@kernel.org, mingo@redhat.com, namhyung@kernel.org, paulmck@kernel.org, pawan.kumar.gupta@linux.intel.com, peterz@infradead.org, rick.p.edgecombe@intel.com, rppt@kernel.org, sandipan.das@amd.com, shijie@os.amperecomputing.com, sohil.mehta@intel.com, tglx@linutronix.de, tj@kernel.org, tony.luck@intel.com, vegard.nossum@oracle.com, x86@kernel.org, xin3.li@intel.com, xiongwei.song@windriver.com, ytcoode@gmail.com Subject: Re: [PATCHv6 07/16] x86/vsyscall: Reorganize the #PF emulation code Message-ID: References: <9d351d80-66fe-486f-bdb3-370859dc47cc@intel.com> <262c0fd2-ac66-4ce7-903f-4062f1fe1d6e@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 8959A1C0002 X-Stat-Signature: yeafpr6w7agrxeq55meounzmr6u3zctf X-HE-Tag: 1750682510-455514 X-HE-Meta: U2FsdGVkX1+Y4k9cyDSyAzRJ89wKJDr3MqW0SgEWnfjOqCilWxkn36yinT8bJ68S94fNGaLW2PhnNwZ1+5VK4EeBEEmjBWe7Ub0DOWY/tBP3cu6Lfchh64wUjeSXGQ7iIE1AAo9ZxW7HF82uJ3JJx1RZ1wv9IfKflMynmteMyCfZUKcimpt/TiXf4AaA4WXs3Z/2xQrF0PS5ptHVI4nI49zSnIHt1H2qvoej/Xz+EekRbH+NCZ0zwRwoAdmBuCLJ3m7Pv48r3ONeT4//JkbXwSTTDw7yyMOWBcixWmAstp0jQv1ipehtDCCzkXaX7VpRFavckdsHjMPInYa08z9vQm8zSAdoKx0XncXB7g0g2/g8Nje9846Oclu+z4AmUQKULi9Gx0H0rIpOIv55ypJjLaayQTaXyHlAJSqOfn15/X4QjKz05UspQ2EQx8il7XcgHFPtv6jNMtY5tix+VZQ3jpikihQOGyX/bw9xhfqI62jPa2dJEXi566sO7gLY/CoeksG5Km6HAsOHz75VIHwOlQD0N4L03J//VEJi1wwIrqxWe7sy5p49CwT183PteP/u58hTi7I2vPRq6rSd+HMelSm771SXfYBs2neITqJmzp7488MWxhjRb/+B0JZOCno7KFgfkF1hVbxLZ2bjODePysWWZpS1j2R8EL4odAuLLkYbnQ07FFzxrHvppLj+YQToL+DKrUYHyFUkEXFWBubUotTHiO2EZwK4rqMhoNsOvez8C06pH4KLI4hxAd3cAIWrRfRsm5YLScW3YfDVytD5GMcEtEKLbrxi3UPSSNRsFOawoI2E8Xp+PZo6D5zaBBxicXJgeAExzcGQk6z/znOXOGwUX0IR6PDFGlNdKxzM9Fm5Y4iaEjV+EpOFk1NE+fqKHhrV9tNxVgaMCAEbuUS80Sni7DDt26bJLO9NnuMBBPQ630YID857r+GpeMvnzP/kkAneAofxzP6PcFhcvRa dlBIsgiO vhE4OzqU9vYurWmRf6ydsnkM6vZQKpza5L/ZFzVOasvkN3IEF9xLKcWMdE3mWc+j82Y1Tqlfgz595iisE3BY9I7ExoezK4aifERXw4ZySJRix/x1aLEv87mig0KZPlNqjLTN6FgxKCtl4hGHWxWD4TSWHs3XsZRipbBFrH53Zn/weFd4steFovFGcgMdiXyc3F1saKDk8yvrESo/pMZGIrwlkykcuDO7T7VwevTy01WR12cXy4OAJBk7gYb0lyFtbdf/pFFyMon3xkXo= 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: List-Subscribe: List-Unsubscribe: On Fri, Jun 20, 2025 at 04:21:38PM -0700, Dave Hansen wrote: > On 6/20/25 16:08, Andrew Cooper wrote: > >> But, the resulting code is wonky. It needs to do something more like this: > >> > >> if ((error_code & (X86_PF_WRITE | X86_PF_USER)) != X86_PF_USER) > >> return false; > >> > >> if (error_code & X86_PF_INSTR)) > >> return __emulate_vsyscall(regs, address); > > To do this, LASS needs a proper interlink against NX || SMEP. > > > > If neither NX nor SMEP are active, the CPU does not report X86_PF_INSTR, > > meaning that fetches are reported as plain reads. > Interesting point. > > I think the easiest way to do this is just make a cpuid_deps[] entry for > LASS and NX. If there's a CPU where LASS is available but where NX isn't > available, we have much bigger problems on our hands. I am not sure what I suppose to do here. Sohil pointed out that with LASS we get #GP on vsyscall, not #PF and PFEC is not relevant for LASS. So, IIUC, that's dependency of vsyscall PF on NX. Do we want to disable vsyscall on boot if NX is not available? BTW, why do we even support !NX on X86_64? Is there such HW? -- Kiryl Shutsemau / Kirill A. Shutemov