On Thu, Nov 24, 2011 at 4:27 PM, Peter Maydell <peter.maydell at linaro.org> wrote: > On 24 November 2011 20:11, Christoffer Dall <cdall at 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. hmm yeah, that could have been an approach. What happened was that before a15, I had to take care of stuff like cache flushes inside the kernel, so it wasn't really an option anyway. > > 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? regarding (a), yes most certainly and (b), not if I can avoid it :) > > 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. > for the record, I wasn't questioning that the refactoring was a good idea, I'm sure it is. >>> 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... > ok. I didn't do much performance tuning yet overall, but I do see virtio and generic timers and being pretty high on the list once we get there, so yes, let's start thinking about it. >> 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). > 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. >> 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. 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. 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?). -Christoffer
