Home Home > 2013 > 10 > 01 > SUSE Speeds up Building AArch64 Software in QEMU
Sign up | Login

SUSE Speeds up Building AArch64 Software in QEMU

October 1st, 2013 by

ARM AArch64 logo
Following the announcement of much improved Raspberry Pi support, there is more news coming from the openSUSE ARM team! The SUSE team has been developing an AArch64 port of QEMU which is much faster building 64 bit ARM code in emulation and this code is aimed for upstream inclusion. Read on to find out what this is all about.

AArch64 Port Written and Released

SUSE engineers have taken up QEMU and developed an AArch64 port. This allows building AArch64 software in emulation with a 10-20x speedup over Foundation model provided by ARM. The speed improvement is a result of the QEMU using user mode, also known as application mode, emulation and not full system mode emulation which is what the Foundation model uses. The code has been employed to advance the AArch64 porting work done in openSUSE, enabling AArch64 as build target in the openSUSE Build Service. SUSE has been able to open source the code and is working on inclusion in upstream QEMU. For those interested, the code is also publicly available on Github.

arndale cluster used in OBS

Bringing openSUSE to AArch64

The Open Build Service in action at openSUSE has recently received a pretty serious upgrade with an impressive Arndale ARM cluster. But before we received this fantastic hardware our x86 based systems were running QEMU Virtual Machines to build the ARMv7 packages under construction. Our engineers had spent effort on the ARMv7 support in QEMU and getting it all well integrated in OBS which improved reliability and support significantly.

Having all this set up in OBS was of course a big help when the team got started on AArch64 and did play a major role in openSUSE being the first generally available, fully built, general purpose Linux distribution for AArch64. We already delivered the experimental AArch64 images with the openSUSE 12.3 release in March 2013!

Build Performance Improvements with AArch64 for QEMU

ARM’s Foundation Model, which is the reference emulation platform, was used to build the packages. It has been an invaluable tool to bring up the distribution but building took long and when there were problems, waiting two days for a rebuild to complete just because somebody made a typo was very frustrating. SUSE engineers thus proceeded to develop AArch64 emulation in QEMU. The AArch64 port for QEMU provides significantly shorter build times both on developer workstations as well as on the Open Build Service and allows development to proceed even more rapidly.

Compared to the already available state of openSUSE:Factory built for AArch64 in the Foundation Model, work has been put into rebuilding all of it with the newly published QEMU emulator, which allows us to follow changes in Factory much quicker than before. The build results are available same like before under openSUSE:Factory:ARM page just like before, however the results are now referring to a QEMU based build.

Have a lot of fun building AArch64 packages!

Both comments and pings are currently closed.

2 Responses to “SUSE Speeds up Building AArch64 Software in QEMU”

  1. Tim Northover

    Awesome work! I’m really pleased to see an OSS emulation platform, and I loved user-mode qemu when I used it before. As you say, massively quicker than a full system emulation if it provides the features needed.

    I couldn’t see any details on what’s supported, does that mean Scalar+NEON should all be working? And crypto? Those are the 3 main variants I know of.

  2. Alexander Graf

    Great to see you like it :). I’m not sure I fully understand the question though. NEON is all part of the ARMv8 specification now. I don’t think I’ve seen crypto instructions in the spec, but I might be wrong.

    Overall, we currently emulate about 90% of the full ARMv8 instruction set. So for a lot of use cases (almost everything compiled by gcc for example) it’s already very usable, but if you hit an illegal instruction, better check the spec to see if it’s not just missing emulation code.