On 25.11.2011, at 00:06, Peter Maydell wrote:
On 24 November 2011 22:02, Christoffer Dall cdall@cs.columbia.edu wrote:
On Thu, Nov 24, 2011 at 4:27 PM, Peter Maydell peter.maydell@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 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