[Android-virt] plans for QEMU support for KVM on ARM
agraf at suse.de
Thu Nov 24 23:10:02 UTC 2011
On 25.11.2011, at 00:06, Peter Maydell wrote:
> On 24 November 2011 22:02, Christoffer Dall <cdall at cs.columbia.edu> wrote:
>> On Thu, Nov 24, 2011 at 4:27 PM, Peter Maydell <peter.maydell at linaro.org> wrote:
>>> Pretty high up my todo list was rebasing your kvm patch on to
>>> master / qemu-linaro (the two are more or less the same for this
>> if you could take charge on that it would be awesome from my point of
>> view. I will send you a (slightly) cleaned up patch that you can use
>> or throw away.
> That would be good, thanks. I'll try to get that rebasing started
> tomorrow and done early next week.
>> I'm already reluctant, so I'm happy to hear there will be some
>> "official" instructions available. I actually think it's important for
>> the adoption of KVM that things are somewhat possible to build without
>> too much jumping through hoops.
> Well, once we've got real hardware it'll be more straightforward
> because building QEMU on the hardware won't be quite so slow...
> Most of this is just because crosscompiling is and remains painful.
> (Alas, you can't compile QEMU in a QEMU arm-linux-user chroot,
> because gcc segfaults. I blame our mmap emulation layer.)
Just throw in MAP_32BIT in all mmaps and it should work like a charm :).
>> A remaining item is to test this setup
>> with the KVM stuff, but it should be a minor thing as long as the
>> kernel headers for KVM/ARM can be integrated with the build process
>> somehow. (Or is there an alternative?).
> Ah, kernel headers, good point. QEMU now carries the KVM kernel
> headers in its own git tree (this has changed since the QEMU version
> you based your original kvm patches on, I think). So we'll have
> to carry the ARM header changes in qemu-linaro too (I think).
> I guess that should be OK, presumably we won't be revising the
> kernel-userspace ABI at a rate of knots. (when the headers get
> upstream in the kernel upstream qemu can update to get them from
> there and we can drop the temporary copies in qemu-linaro).
> [that's kind of off-the-top-of-my-head, yell if it sounds lunatic.]
I fully agree. Treat the linaro tree as the temporary straighten-out-the-ABI-tree and then move to upstream for further development :)
More information about the linaro-toolchain