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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9FB2FC7EE25 for ; Fri, 9 Jun 2023 00:23:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230011AbjFIAXC (ORCPT ); Thu, 8 Jun 2023 20:23:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42194 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229732AbjFIAXB (ORCPT ); Thu, 8 Jun 2023 20:23:01 -0400 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1F0A22D72; Thu, 8 Jun 2023 17:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1686270180; x=1717806180; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=hfORcgQzuOPbSklLPJdOW8LVCo5d5Go2LF+sADUuhiU=; b=KKj2g/8okkDMbg1JK1vlqBo5WO8T2Yg1lw+o3aF091wCdUalOduElHZE /Dm25vHxeFMHoGjV6sWSn5Su2YITlWNga4vMxgXE7dDv2kaHbMS3GgBB+ DCsYj58YJHY0MfAkyw2mT/fLUsyKAEFZ2x91wIwyDoHDjHnn0rfnygqnq udMIAAAlFmWvv9fmmv5e32stVYtfwOz2z395WKhNnSwHjmxOv0irJ/KtP KzeYl+aU2ZmFXkRyjXDZ/qalA+IdSgFWcYDGP09H4ACBHSCXnlwt9A+rT 1DmVw/jx3J7LG0OkeF6IfOuLjqXQU3ZbmHyMi3UlFPQ34jSHNAptUCuBJ A==; X-IronPort-AV: E=McAfee;i="6600,9927,10735"; a="421061871" X-IronPort-AV: E=Sophos;i="6.00,228,1681196400"; d="scan'208";a="421061871" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2023 17:22:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10735"; a="884393196" X-IronPort-AV: E=Sophos;i="6.00,228,1681196400"; d="scan'208";a="884393196" Received: from yjiang5-mobl.amr.corp.intel.com (HELO localhost) ([10.144.161.97]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2023 17:22:57 -0700 Date: Thu, 8 Jun 2023 17:22:57 -0700 From: Yunhong Jiang To: Andrew Cooper Cc: Thomas Gleixner , "Kirill A. Shutemov" , LKML , x86@kernel.org, David Woodhouse , Brian Gerst , Arjan van de Veen , Paolo Bonzini , Paul McKenney , Tom Lendacky , Sean Christopherson , Oleksandr Natalenko , Paul Menzel , "Guilherme G. Piccoli" , Piotr Gorski , Usama Arif , Juergen Gross , Boris Ostrovsky , xen-devel@lists.xenproject.org, Russell King , Arnd Bergmann , linux-arm-kernel@lists.infradead.org, Catalin Marinas , Will Deacon , Guo Ren , linux-csky@vger.kernel.org, Thomas Bogendoerfer , linux-mips@vger.kernel.org, "James E.J. Bottomley" , Helge Deller , linux-parisc@vger.kernel.org, Paul Walmsley , Palmer Dabbelt , linux-riscv@lists.infradead.org, Mark Rutland , Sabin Rapan , "Michael Kelley (LINUX)" , Dave Hansen Subject: Re: [patch] x86/realmode: Make stack lock work in trampoline_compat() Message-ID: <20230609002257.GA3661@yjiang5-mobl.amr.corp.intel.com> References: <20230508185218.962208640@linutronix.de> <20230524204818.3tjlwah2euncxzmh@box.shutemov.name> <87y1lbl7r6.ffs@tglx> <87sfbhlwp9.ffs@tglx> <20230529023939.mc2akptpxcg3eh2f@box.shutemov.name> <87bki3kkfi.ffs@tglx> <20230529203129.sthnhzgds7ynddxd@box.shutemov.name> <87h6rujdvl.ffs@tglx> <20230608233402.GA3430@yjiang5-mobl.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-csky@vger.kernel.org On Fri, Jun 09, 2023 at 12:57:46AM +0100, Andrew Cooper wrote: > On 09/06/2023 12:34 am, Yunhong Jiang wrote: > > On Tue, May 30, 2023 at 12:46:22PM +0200, Thomas Gleixner wrote: > >> The stack locking and stack assignment macro LOAD_REALMODE_ESP fails to > >> work when invoked from the 64bit trampoline entry point: > >> > >> trampoline_start64 > >> trampoline_compat > >> LOAD_REALMODE_ESP <- lock > > One possibly dumb question and hope get some hints. > > There's a phrase.  "The only dumb question is the one not asked". > > If you have this question, there's an excellent chance that someone else > reading this thread has the same question. > > > The LOAD_REALMODE_ESP is > > defined under .code16 directive and will be used by 32-bit mode caller also. Is > > it ok because the instructions there will be same for both 16-bit and 32-bit? I > > checked > > https://ftp.gnu.org/old-gnu/Manuals/gas-2.9.1/html_chapter/as_16.html#SEC205 and > > don't find much information there. > > The position of the LOAD_REALMODE_ESP .macro itself doesn't matter.  > It's just some text which gets pasted elsewhere.  Imagine it just the > same as running the C preprocessor on a file before compiling it. > > As you note, some expansions of the macro are in .code16, and some are > not.  This does result in different bytes being emitted.  The default > operands size flips between .code16 and .code32, so there will be some > 0x66 prefixes in one mode, and not in others. > > The important point is the l suffix on btsl, which forces it to be long > (32bit) irrespective of the default operand size. > > So yes, it will work, but that's because gas is handling the differing > encodings automatically based on the default operand size where the > LOAD_REALMODE_ESP gets expanded. > > Hope this helps, Thank you for the explaination, it's quite clear now. > > ~Andrew