This isn't strictly a requirement for KVM, but we're going to want KVM to be able to hand off cp15 accesses to QEMU, and I don't think that's going to be maintainable or reliable without this refactoring.
Why do we need KVM to hand off cp15 accesses to QEMU? As of now almost all of this is supported in-kernel. Do the CP15 behavior vary that much according to the board config? I would think that other co-processor accesses would actually be more important if they're used as interfaces for DSPs etc. But in that case, yes, we need a way to handle them at least.
[snip]
Also on the radar is a fourth piece of work:
* QEMU virtio-mmio support
This is adding support for the 'mmio' virtio transport, which will allow virtio support in a versatile-express model. We're going to need this at some point but the current thought is that we want to do the above listed more important bits of work first... (The exception would probably be if it turned out that this was sufficiently useful for making early KVM development easier)
I don't really see why it would be. Is this not merely a question of performance?
So, questions: (1) did we forget something important? (2) is anybody else already planning to do any of this (or would like to start)? if so we should coordinate... (3) is there anything that the kernel folk need/want earlier rather than later?
Thanks for sending this out.
I would like some clarity (if possible) of which branch the KVM support for ARM should be based on. Is it the Linaro version of QEMU and basically just keep rebasing the changes off there until someone accepts them or?
What would be helpful from the point of view of KVM is to have basic ARM host support and the A15 system model upstream.
Currently there are a number of changes to the configure script to make things work and we link against a prebuilt zlib library that we keep distributing to people who wish to build QEMU for KVM/ARM. I am not an expert on QEMU and would definitely like some help on doing this the right way. What's the recommended procedure? Should I send out the hack-ish patch we have now, and if so, what should be the base of such a patch.
Best, Christoffer