* Attended LinuxCon Europe / ELC-Europe / QEMU Summit / KVM Forum
(an overlapping set of conferences across a week in Barcelona)
LCE/ELC: brief summary of interesting sessions (I've only listed
ones which seem most relevant to ARM just to keep the length of this
report down):
* "Devicetree and its stumbling blocks" -- a view from a kernel
developer perspective of some of the issues with doing platform
data to dt conversions: (a) dt is supposedly OS independent and
an external ABI, implying more need for cleanliness and long term
supportable interfaces. (b) conversions imply a need to generalise
bindings to be usable across many devices (c) what do we do about
configuration / policy choices?
My take is that the kernel folks are tying themselves in knots
to try to preserve the (somewhat fictional in practice) idea that
any kernel will work with any older device tree blob and they'd
find it easier if they declared an amnesty for breaking changes
before some deadline date...
* Developing and testing industrial hardware with QEMU
Rather than developing/testing sw against expensive/limited
availability hw, use a model -- easier automation, ability to
simulate error conditions, etc. If your hardware is basically
a PCI card in an x86 box QEMU's fairly easy to use for this.
* UEFI Secure Boot
A summary of the current status of UEFI Secure Boot: it's mandatory
for Win8 hardware; Linux implication is that we need to be able to
maintain simple "out of box boot off distro CD"; optionally, if we
have end-to-end signed binaries we have access to environments which
will end up mandating it (read: government). Fortunately people
have come together to tackle this and it looks like we're in good shape.
http://mjg59.dreamwidth.org/18945.html is a good summary.
* Kernel report by Jonathon Corbet
ARM featured fairly prominently in this stats-driven roundup:
64-bit ARM support was first listed bullet point for 3.7 features
Pointed out that Linaro and other embedded-ARM kernel contributions
are notably up, ARM mess has been cleaned up.
KVM Forum:
* Concurrency in QEMU
Plans for splitting QEMU's "big lock" into finer grained mutexes;
should improve I/O scalability for KVM guests and realtime guest
latency. However some tricky locking design issues to be solved.
I am as usual sticking my oar in occasionally to remind people that
the world is not solely x86-and-PCI...
* qtest
A summary of QEMU's new qtest framework, how it works and how to
write tests. We're going to start insisting on test cases for new
patches, so I need to write some basic tests for a few ARM devices
so I know how it works :-)
* ARM Virtualization for the Masses
Christoffer Dall's talk introducing the ARM virt. extensions and KVM
work. Well received, various questions afterwards (some elements of
"why doesn't this work the way the x86 stuff does", also lots of
"does this work on the Samsung/Google Chromebook" :-))
QEMU Summit:
* This was an invite-only afternoon with perhaps 20 or so of the
main QEMU contributors; broadly focused on "process" issues like
release management, patch flow and security bug handling. Productive
session; minutes should be available on the QEMU mailing list shortly.
This is likely to be repeated next year.
Informal discussions (IME the most important and worthwhile part):
* virtio related : ran through current status of virtio-mmio patches
with Anthony Liguori and Alex Graf, confirmed what changes we need
to make and what the next steps with this should be. Some enthusiasm
for getting this patchset in in the early part of the QEMU 1.4
release if we can. I'm really happy that we've unblocked this bit of
work which had stalled slightly trying to figure out the right approach.
Long term we will probably end up using virtio-pci on ARM but this
is really dependent on hardware with good PCI support appearing.
* SystemC : the upstream community is not currently interested in
SystemC support, but there is some work on the QEMU core which would
be a useful cleanup for QEMU itself and also useful for the SystemC
folk. I'm hopeful that this might help to bring people working with
QEMU in SystemC closer to the "QEMU upstream" community and mailing
list, but it will be a gradual process both socially and technically
if it does happen.
* an informal enquiry about whether system emulation of virt. mode
in ARM was planned or how much work it would be
* in-kernel-irqchip: common ABI cross architecture
the current ABI is a bit x86-specific, useful discussion about
what POWER/S390/ARM would need. There will probably be some more
ioctls coming along but the good news is that what the KVM ARM
patches have currently fits into the proposals with only a very
trivial tweak; we can add support for the new ioctls later if
they are useful for us.
-- PMM
== Blueprints ==
Initial Current Actual
initial-aarch64-backport 31 Oct 2012 30 Nov 2012
aarch64-baremetal-testing 31 Oct 2012 30 Nov 2012
fix-gcc-multiarch-testing 31 Dec 2012 31 Dec 2012
backport-fma-intrinsic 31 Dec 2012 31 Dec 2012
fused-multiply-add-support 31 Dec 2012 31 Dec 2012
gcc-investigate-lra-for-arm 31 Dec 2012 31 Dec 2012
== Progress ==
* Returned from Connect and followed up.
* Updated performance blueprints for next iteration
* Backporting Doko's triplet patches to 4.7
* Patches ready except for problems building Ada
* HOT/COLD partitioning
* Rebuilt with TBB/TBH disabled always
* Started investigated LRA for ARM
== Next Week ==
* Post triplet backport patches upstream
* Run HOT/COLD partitioning benchmarks
* On ARM to see if TBB/TBH is making the difference previously seen
* On x86_64 to see what the actual benefit we could get
* initial-aarch64-backport & aarch64-baremetal-testing
* Finish documentation
* gcc-investigate-lra-for-arm
* Benchmark on x86_64 to see what the benfit could be.
* fix-gcc-multiarch-testing
* Come up with strawman proposal for updating testsuite to handle
testing with varying command-line options.
== Future ==
* backport-fma-intrinsic & fused-multiply-add-support
* Backport patches once fix-gcc-multiarch-testing has been done.
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
Dear all,
we have an ARM Cortex-A8 board where we are running our application. I am in charge of maintaining the Linux on it and the toolchain/SDK setup. So far we've been running Poky/OpenEmbedded and using the cross compiler that came about during the compilation.
For easier maintenance, we are now switching to Linaro. The image is set up and I can compile, however I notice a peculiar fact: the binary distribution of Linaro's gcc (https://launchpad.net/linaro-toolchain-binaries/trunk/2012.10/+download/gcc…) has a significantly larger compilation speed than a version of arm-linux-gnueabihf-gcc that is shipping with Ubuntu. In our particular case, using Ubuntu's version it takes less than 6 minutes to compile our software, but 10 minutes when we use Linaro's version. The makefiles and source are exactly the same, only the compiler is different. I also tried an older version (4.6) of Linaro's gcc to match the Ubuntu one (tested the 12.04 shipped version), with no significant difference.
Compiler flags for the system are -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=hard
Running with -ftime-report, most of the additional time seems to be spent in the parser. Adding -fno-graphite-identity -fno-graphite for Linaro's gcc did not make a difference.
I believe I tried to use crosstool-ng to make my own version, but I don't remember the results as this was over 7 weeks ago. I also did not have a chance to compare performance of the binaries. I do notice a difference in compilation sizes (4.8 MB for Ubuntu's 4.6 version, 4.1 MB for Linaro's 4.7 versions - can't test anything other right now).
I would like to use Linaro's gcc as the crosscompiler for our project, as it is an easy setup. Repackaging Ubuntu's version is an option, though (some of the team do not use Ubuntu, plus I'd like everybody to use EXACTLY the same version of the crosscompiler). So there is no real "problem" for me, per se, but I am extremely curious as to what is going on here. It seems that Linaro's gcc has additional patches or maybe just different default settings that cause additional time to be spent in the parser. It would be interesting to know what exactly this is and whether/how it can be disabled in those cases where time of compilation is more important than e.g. performance gain.
TIA for replying.
Best
Frank
* Attended Linaro Connect; notable sessions:
+ Ubuntu plans for QEMU for Ringtail release
= upstream qemu has merged qemu-kvm back in so
Ubuntu will switch to qemu from qemu-kvm for x86
= also makes sense now to use upstream qemu for all archs
(following Debian) rather than using qemu-linaro for non-x86:
reasons for using q-l in Ubuntu now mostly fixed (ie upstream
ARM support no longer dire). Ubuntu will carry omap3 patches
to avoid dropping that feature in the changeover
= makes sense for Linaro too as we now have an automated
package-to-PPA setup for people who need bleeding-edge and
also will want Ubuntu to transition to a more stably released
and supported QEMU codebase to use for KVM-on-ARM-servers
+ KVM Testing plans
= worked through a list of things that would be nice to test;
useful feedback from people in the session about what matters.
Missing: specific commitment by anybody to write tests :-)
+ various informal discussions about possibilities for v8 QEMU
* this week: at LinuxCon Europe / ELC-Europe / KVM-Forum / QEMU Summit
-- PMM
Hi toolchain people,
I've gone through and massaged our meetings and 1-on-1s to handle the
recent daylight savings changes. Most meetings now start at 9:15 am GMT
and 1-on-1s are packed before them if possible.
Let me know if I should massage them further,
-- Michael
== Progress ==
* Attended Linaro Connect
* Worked out focus for performance in next iteration:
* Cortex-A15
* Other discussions on:
* Transitioning from cbuild->LAVA
* ARMv8 GNU Tools support
* big.LITTLE Toolchain tuning
== Next Week ==
* Backport Doko's configury changes for arm-none-linux-gnueabihf support
* Remerge HOT/COLD partitioning to test like for like (TBB generation)
* Benchmark LRA vs Reload on x86 and x86-64
* Write up strawman for non-multitest testing in GCC
== Future ==
* Decide whether the effort to develop HOT/COLD partitioning is worth it.
* Support LRA on ARM.
* Attend Connect in Hong Kong...
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
