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

[Peter Maydell]

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.

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