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

[Christoffer Dall]

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