[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch] x86/realmode: Make stack lock work in trampoline_compat()


  • To: Yunhong Jiang <yunhong.jiang@xxxxxxxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Fri, 9 Jun 2023 00:57:46 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=twRHBMfVYuU/sueZMOcTln+DbJUpGF3uGhwyeaWZnqc=; b=QhzP205u0k7zky00uwfaOjDEWDduxqIGSx4NWY5VBWvm9hSYJ8tYAvoQ6ekSjU3Ax97YmZOY0FgAS34TQushF39dnuTI/ah+nAxgDdeF4PpiXKrywsD9ZyYmhWUvSut4fMjhSinhL7ik1d5a1RpFSar3uiNEixyHOdLXRQCJhpkQXdFq7rDWjsp5bUJVJqrNaV1WH/RDGtbI4OyxZ/gLMr2Kl4edX8DOAWFMLfK1+oH0gnrMUamgy6g1n6TCjpa/tUFfGAdn1L6IQQU81tOagtS5Nd/CDfBSewxnFgTlQXtOTMJDPpmnQeq1WQ/di6emlQfzp9rjblF83xXT/2ivXA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gChBozy6rNxYIJAUxZ0R7D/onMQY9kV7D7T25x+QDCLOUu9vbpOVkQqk2S2yXYtPEPXqx2TU5xTdWd6V6Gf23A75rXUfwKgy/H2qL/7Qrg4TLDETmrRIgUl3kx5Ul5IDtNnxuaPd6GeiP3yWwDe1Ql3AsPkkvLf4p91J5d/zdoSbZjx7lsdljwIDB7qNEnekxn+2CbsyNn8q5IzxI4ZPoosH0qIPxEiHxXq0cIm/nQM/QIkIaoCF+Ha+R/PDvW4PNKpg5MJGsWMe8YvrbnAKHr2bpQr59kczhL17neuBdGRmrQ18b/rDcCTgPK1sNOqP73WYjrPNMaqneASqlMJH2A==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>, x86@xxxxxxxxxx, David Woodhouse <dwmw2@xxxxxxxxxxxxx>, Brian Gerst <brgerst@xxxxxxxxx>, Arjan van de Veen <arjan@xxxxxxxxxxxxxxx>, Paolo Bonzini <pbonzini@xxxxxxxxxx>, Paul McKenney <paulmck@xxxxxxxxxx>, Tom Lendacky <thomas.lendacky@xxxxxxx>, Sean Christopherson <seanjc@xxxxxxxxxx>, Oleksandr Natalenko <oleksandr@xxxxxxxxxxxxxx>, Paul Menzel <pmenzel@xxxxxxxxxxxxx>, "Guilherme G. Piccoli" <gpiccoli@xxxxxxxxxx>, Piotr Gorski <lucjan.lucjanov@xxxxxxxxx>, Usama Arif <usama.arif@xxxxxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, Russell King <linux@xxxxxxxxxxxxxxx>, Arnd Bergmann <arnd@xxxxxxxx>, linux-arm-kernel@xxxxxxxxxxxxxxxxxxx, Catalin Marinas <catalin.marinas@xxxxxxx>, Will Deacon <will@xxxxxxxxxx>, Guo Ren <guoren@xxxxxxxxxx>, linux-csky@xxxxxxxxxxxxxxx, Thomas Bogendoerfer <tsbogend@xxxxxxxxxxxxxxxx>, linux-mips@xxxxxxxxxxxxxxx, "James E.J. Bottomley" <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>, Helge Deller <deller@xxxxxx>, linux-parisc@xxxxxxxxxxxxxxx, Paul Walmsley <paul.walmsley@xxxxxxxxxx>, Palmer Dabbelt <palmer@xxxxxxxxxxx>, linux-riscv@xxxxxxxxxxxxxxxxxxx, Mark Rutland <mark.rutland@xxxxxxx>, Sabin Rapan <sabrapan@xxxxxxxxxx>, "Michael Kelley (LINUX)" <mikelley@xxxxxxxxxxxxx>, Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 08 Jun 2023 23:58:20 +0000
  • Ironport-data: A9a23:G9JWDK1jShIruvFwRfbD5Ux3kn2cJEfYwER7XKvMYLTBsI5bpz0Az zQYWm2GOquCYjPyKdt/PN62oxkPv5/dx9NjQFRvpC1hF35El5HIVI+TRqvS04F+DeWYFR46s J9OAjXkBJppJpMJjk71atANlVEliefTAOK6ULWeUsxIbVcMYD87jh5+kPIOjIdtgNyoayuAo tq3qMDEULOf82cc3lk8teTb8HuDgNyo4GlD5gJmNagQ1LPjvyJ94Kw3dPnZw0TQGuG4LsbiL 87fwbew+H/u/htFIrtJRZ6iLyXm6paLVeS/oiI+t5qK23CulQRrukoPD9IOaF8/ttm8t4sZJ OOhF3CHYVxB0qXkwIzxWvTDes10FfUuFLTveRBTvSEPpqFvnrSFL/hGVSkL0YMkFulfC0Zp2 6wmBDE2d1OknbqYmouxTMpCiZF2RCXrFNt3VnBI6xj8Vaxja7aaBqLA6JlfwSs6gd1IEbDGf c0FZDFzbRPGJRpSJlMQD5F4l+Ct7pX9W2QA9BTJ+uxqui6PnWSd05C0WDbRUvWMSd9YgQCzo WXe8n6iKhobKMae2XyO9XfEaurnxHqhAd9JS+PjnhJsqEGBmnciUiQ2bnWi+ffguk+kZPxlG mVBr0LCqoB3riRHVOLVTgC+oHmCsVgeWtNWHMU+6QeQ2uzV5RqUAi4PSTspQNU8ssMeTCYs2 lXPk96BLThutqCFDHuH8/KXoCm0NCw9KW4ZeTRCTA0L+dDvrYg/yBXVQb5LG6eph9n0H3f1y iqLqiElr7wJiIgA0KDT1U/GhzaEpZXTSAMxoALNUQqN4R5+foOjT4+l817W6bBHNonxZl2Au mUU3sOF7/EmE56AjmqOTf8LEbXv4OyKWBXAmlRoEJQn+xyk/2ajdMZe+jh4J0pvdMoJERftY UnOqStY/ppXPX23felweY33FsdC5azhE8n1E/XVdsFmfJd8bkmE8TtoaErW2Hri+GAgnKU7N I2zfsO8S3oXYYxjzTyrV6IF2KUq3SsW22zeX9b4wg6h3L7YY2SaIZ8dOUaKKP8w6KafpAjE2 81eOcqUxlNUV+iWSjHe9YseN3gGJHIxCJTq7cdQc4arJgtgBXFkEf7Kyq0Jf41+g78Tl+HG5 HixV0ZUjl3lihXvLAyQaTZ5da/rVJBzhXshOGonOlPA82Mqa5ym9K4ZX5IydKsg8qpoyvscZ 9sMfsibRN5IVijA/jAQfLH9pYp5eRKzjBiSOSe/ezg+Z9hrQAmh0trlfQbr8CQfJi+2vtE5u LquykXQRp9rbxRvCoPaZeyiy3u1vGMBg6RiUk3QON5RdU7wto9wJETZjPAtJNoXAQ7e3Tbc3 AGTaT8Equ3di4s09sTVn6eCrpfvH+YWNklbBWjf6Z6tNTTG82+k38lGWeOFFRjZVWXp6OCha P9TwvXULvIKhhBJvpB6HrItyrgxj/P/9+FyzQl+GnjPKVOxBdtILmaDwpNnt6tD3LZVtAK6H EWV9bFyM6+GNdn+DHYeIQMkaqKI0vR8sjDI7/0zCEH74jJnuruBTUhWeRKLjUR1JrxvMZhjx vw9oskI8A+uoh0wO92Cg2Zf8GHkBmQKVKM1t5cbKJXmhgoi1hdJZpm0IjP255SGcJNIP08mK zSXlYLLgrgazU3HG1IoGHHL3+F1ipMJtxRHilQFIjyhnd7IheQ+2hFL2TI+Ug1RwxNE1KR1M 21mX2VtIKiI7TpsrM1EW2+hHUdEHBLf9kGZ41QRlWbSSE2pfm3CJWk8MKCG+0Vx22ZBdTpS+ vec1W3nWDDtYun+2yIzXQhurPmLZcFq/wjL3sm9HsqtFYgmbDbshKSjI2EPrnPPGcosgEjMp sFp8fx2ZKm9MjQfy4U3ApeXk7QZTguJIkRGQPd87OUIG33RfHe53j3mFqyqUsZEJviP+0nhD cVrfphLT07miHfIqS0HD6kRJbMyhOQu+NcJZrLsIygBrqebqT1q9pnX80ASmVMWfjmnqu5lQ qu5St5IOjX4aad884MVkPR5Bw==
  • Ironport-hdrordr: A9a23:BTum3aoOgB0d1kSzX8QiLFoaV5rveYIsimQD101hICG9Evb0qy nOpoV/6faQslwssR4b9uxoVJPvfZq+z+8W3WByB9eftWDd0QPFEGgL1+DfKlbbak7DH4BmtJ uJc8JFeafN5VoRt7eG3OFveexQvOVu88qT9JjjJ28Gd3APV0n5hT0JcjpyFCdNNW57LKt8Lr WwzOxdqQGtfHwGB/7LfUXsD4D41rv2fIuNW29+OyIa
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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,

~Andrew



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.