* 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

_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Reply via email to