On 24 November 2011 20:11, Christoffer Dall cdall@cs.columbia.edu wrote:
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.
I think it was mostly the generic timer that inclined me that way: it's a device that just happens to be hung off the cp15 interface rather than being memory mapped.
My assumption was that initial default would be "hand everything off to qemu" with the kernel then providing implementations of things like timers for performance reasons later.
Also, there are lots of cp15 registers, and they vary between implementations, so (a) it would be useful to share the emulation implementation between qemu and kvm somehow and (b) are you really going to implement cp15 emulation for half a dozen CPU implementations in the kernel?
If it doesn't make sense to hand off cp15 accesses that's fine, though -- I want to do this refactoring for the A15 system mode implementation in qemu anyway, because I really don't think we should try to shoehorn in yet another cpu implementation into the current set of switch statements...
It looks (from a brief glance at the code) like ppc kvm does handoff-to-qemu with the DCRs, incidentally.
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?
Yes; Marc Z was complaining at me earlier this week about SD card emulated performance being particularly dire, though :-) So this is kind of down here as a "if anybody wants this sooner than some-time-late-next-Q1 now is a good time to scream" marker...
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.
My plan here was that the bits like A15 system model which are clearly upstreamable I would push directly upstream (and just keep in qemu-linaro for the typically week-or-three things take to go through upstream patch review). For the KVM support patch itself, my thought was simply to carry that in qemu-linaro as an "unsupported work in progress" patch until we think it's ready to commit upstream. [I'm suggesting qemu-linaro here mostly because it's convenient to me: it's a tree I already maintain and track upstream trunk with. If that would be awkward for other people we can do something else.]
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).
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 have some instructions for Ubuntu oneiric hosts that work by using the stock oneiric ARM zlib (installed via dpkg-cross): see the section at the bottom of https://wiki.linaro.org/PeterMaydell/A15OnFastModels (that's "how to cross build upstream qemu master", not your qemu with the kvm patch.)
You'll find that when we update to QEMU 1.0 you'll also need a cross version of the glib/gthread libraries, which may make you more reluctant to stick to the "hand out prebuilt cross library" approach.
-- PMM