qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alexander Graf
Subject: Re: [Qemu-devel] [Android-virt] plans for QEMU support for KVM on ARM
Date: Tue, 22 Nov 2011 16:05:03 +0100

On 22.11.2011, at 15:44, Peter Maydell <address@hidden> wrote:

> This email is just a quick summary of what we (Linaro) are
> planning in the way of QEMU work to support KVM on ARM Cortex-A15.
> The idea is to let people know what's coming up, find out if we've
> forgotten anything, and avoid people duplicating work unnecessarily.
> Most of this is based on a useful session at the recent 'ARM server
> mini-summit' in Orlando (UDS/Linaro Connect) at the beginning of
> this month.
> 
> The work we're currently proposing to do falls into three parts:
> 
> * refactor QEMU's cp15 register handling
> 
> At the moment QEMU handles cp15 accesses by calling out to a single
> helper function which is an enormous set of nested switch statements
> to handle the different coprocessor registers. Access permissions are
> checked separately at translate time. This design makes specifying
> board-dependent or cpu-dependent registers somewhat painful; it's also
> easy for the access permission checks to be out of sync. There is no
> support for banked cp15 registers either (needed for trustzone and
> virtualisation). We need a better design which lets a board or core
> register handler routines for cp15 registers. This will make the code
> cleaner and more maintainable as a base for new features.
> 
> 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.
> 
> (https://blueprints.launchpad.net/qemu-linaro/+spec/cp15-rework)
> 
> * A15 system model
> 
> Basically a QEMU model of a Versatile-Express with a Cortex-A15
> minus the virtualization and LPAE extensions. This needs the
> A15 private peripherals (just the GIC in the right place in
> the memory map, really; generic timer not required) and the
> new memory map version of the vexpress board model, plus some
> new cp15 registers. (Bill Carson has already done some patches
> in this area but they need a little rework and may have minor
> missing pieces.)
> 
> https://blueprints.launchpad.net/qemu-linaro/+spec/initial-a15-system-model
> 
> * miscellaneous integration work
> 
> We're aiming for a reasonable working prototype of A15 guest on
> an A15 Fast Model host here; we need to fix at least some of
> the bugs which currently mean upstream QEMU doesn't work on ARM hosts,

I thought there was upstream tcg support for arm now? What specifically doesn't 
work?

Alex

> sort out which kernel and qemu trees we are developing from, and
> get things running in our validation lab's continuous integration
> setup.
> 
> https://blueprints.launchpad.net/qemu-linaro/+spec/qemu-kvm-getting-started
> 
> 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)
> 
> https://blueprints.launchpad.net/qemu-linaro/+spec/add-amba-virtio-support
> 
> 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
> -- PMM
> _______________________________________________
> Android-virt mailing list
> address@hidden
> https://lists.cs.columbia.edu/cucslists/listinfo/android-virt



reply via email to

[Prev in Thread] Current Thread [Next in Thread]