Re: [Qemu-devel] [Android-virt] plans for QEMU support for KVM on ARM

[Alexander Graf]

On 25.11.2011, at 00:06, Peter Maydell wrote:

> On 24 November 2011 22:02, Christoffer Dall <address@hidden> wrote:
>> On Thu, Nov 24, 2011 at 4:27 PM, Peter Maydell <address@hidden> 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
>>> purpose).
>> 
>> 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 :)


Alex