[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <67f939e112cc4578833ca74123bee402@AcuMS.aculab.com>
Date: Sat, 10 Jun 2023 19:50:58 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Andrew Cooper' <andrew.cooper3@...rix.com>,
Yunhong Jiang <yunhong.jiang@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>
CC: "Kirill A. Shutemov" <kirill@...temov.name>,
LKML <linux-kernel@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
"David Woodhouse" <dwmw2@...radead.org>,
Brian Gerst <brgerst@...il.com>,
"Arjan van de Veen" <arjan@...ux.intel.com>,
Paolo Bonzini <pbonzini@...hat.com>,
"Paul McKenney" <paulmck@...nel.org>,
Tom Lendacky <thomas.lendacky@....com>,
"Sean Christopherson" <seanjc@...gle.com>,
Oleksandr Natalenko <oleksandr@...alenko.name>,
Paul Menzel <pmenzel@...gen.mpg.de>,
"Guilherme G. Piccoli" <gpiccoli@...lia.com>,
Piotr Gorski <lucjan.lucjanov@...il.com>,
Usama Arif <usama.arif@...edance.com>,
Juergen Gross <jgross@...e.com>,
"Boris Ostrovsky" <boris.ostrovsky@...cle.com>,
"xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
Russell King <linux@...linux.org.uk>,
"Arnd Bergmann" <arnd@...db.de>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, Guo Ren <guoren@...nel.org>,
"linux-csky@...r.kernel.org" <linux-csky@...r.kernel.org>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
"James E.J. Bottomley" <James.Bottomley@...senPartnership.com>,
Helge Deller <deller@....de>,
"linux-parisc@...r.kernel.org" <linux-parisc@...r.kernel.org>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
"Mark Rutland" <mark.rutland@....com>,
Sabin Rapan <sabrapan@...zon.com>,
"Michael Kelley (LINUX)" <mikelley@...rosoft.com>,
Dave Hansen <dave.hansen@...ux.intel.com>
Subject: RE: [patch] x86/realmode: Make stack lock work in trampoline_compat()
From: Andrew Cooper
> Sent: 09 June 2023 00:58
>
...
> The important point is the l suffix on btsl, which forces it to be long
> (32bit) irrespective of the default operand size.
Does that matter at all?
The 'bit' opcodes (I'm sure 'bts' is 'bit test and set') take
a bit offset from the base address.
This accesses the same bit regardless of the operand size.
The one real issue is that a byte operand will only lock the one byte.
This might be problematic if non-bit locked accesses are also used.
Although it would need to be rather obscure use.
(This may be one of them...)
The only other problem is that btsl always does a locked 32bit
access. If the base address is misaligned this is a misaligned
locked access - problematic if it crosses a cache line boundary.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists