Bug#771997: swp on armv8 (Was: Haskell on arm needs help)
Source: linux
Version: 3.16.7-2
Severity: important
X-Debbugs-CC: debian-arm@lists.debian.org
On Thu, 2014-12-04 at 08:38 +0000, Ian Campbell wrote:
> On Wed, 2014-12-03 at 23:23 +0000, peter green wrote:
>
> > I vaugely remember something a while back about some deprecated 32-bit
> > arm instructions needing kernel emulation on armv8 and that emulation
> > not being implemented yet.
>
> That's correct, and IIRC swp is one of those instructions.
>
> > AIUI swp is already handled through kernel emulation on armv7
> > multiprocessor systems. There seem to be patches to port that emulation
> > to arm64 but it doesn't appear they are in the kernel tree debian is
> > using.
> > Having 32-bit binaries break on armv8 systems due to lack of the
> > swp instruction does not seem like a good thing so IMO we really want
> > this in our kernels before release.
>
> If those patches have gone into a later upstream kernel than we have in
> Jessie (v3.16) then we should certainly backport them. IIRC they were
> controversial though, so if they haven't hit mainline I'd be *very*
> reluctant to "fork" the v8 userspace ABI.
They are in the arm64 maintainer's for-next/core branch but not in
Linus' tree (yet):
$ git log --oneline v3.16..origin/master -- arch/arm64/kernel/armv8_deprecated.c
$ git log --oneline v3.16..arm64/for-next/core -- arch/arm64/kernel/armv8_deprecated.c
9096339 arm64: fix return code check when changing emulation handler
d784e29 arm64: Trace emulation of AArch32 legacy instructions
c852f32 arm64: Emulate CP15 Barrier instructions
bd35a4a arm64: Port SWP/SWPB emulation support from arm
587064b arm64: Add framework for legacy instruction emulation
I've bcc'd submit@ on this mail to create a bug for tracking. I think
I'm happy to backport now (FSVO "now" depending on when I get a moment),
since these are clearly en route to Linus.
Note that after these patches SWP is still undef by default, this just
adds the option to emulate (via a sysctl toggle). I don't propose to
deviate from upstream here, since they have good reasons to prefer the
current defaults.
Ian.
Reply to: