On Wed, 2011-11-30 at 18:15 +0000, Arnd Bergmann wrote:
On Wednesday 30 November 2011, Ian Campbell wrote:
On Wed, 2011-11-30 at 14:32 +0000, Arnd Bergmann wrote:
On Wednesday 30 November 2011, Ian Campbell wrote: What I suggested to the KVM developers is to start out with the vexpress platform, but then generalize it to the point where it fits your needs. All hardware that one expects a guest to have (GIC, timer, ...) will still show up in the same location as on a real vexpress, while anything that makes no sense or is better paravirtualized (LCD, storage, ...) just becomes optional and has to be described in the device tree if it's actually there.
That's along the lines of what I was thinking as well.
The DT contains the address of GIC, timer etc as well right? So at least in principal we needn't provide e.g. the GIC at the same address as any real platform but in practice I expect we will.
Yes.
In principal we could also offer the user options as to which particular platform a guest looks like.
At least when using a qemu based simulation. Most platforms have some characteristics that are not meaningful in a classic virtualization scenario, but it would certainly be helpful to use the virtualization extensions to run a kernel that was built for a particular platform faster than with pure qemu, when you want to test that kernel image.
It has been suggested in the past that it would be nice to run the guest kernel built for the same platform as the host kernel by default, but I think it would be much better to have just one platform that we end up using for guests on any host platform, unless there is a strong reason to do otherwise.
Yes, I agree, certainly that is what we were planning to target in the first instance. Doing this means that we can get away with minimal emulation of actual hardware, relying instead on PV drivers or hardware virtualisation features.
Supporting specific board platforms as guests would be nice to have eventually. We would need to do more emulation (e.g. running qemu as a device model) for that case.
There is also ongoing restructuring in the ARM Linux kernel to allow running the same kernel binary on multiple platforms. While there is still a lot of work to be done, you should assume that we will finish it before you see lots of users in production, there is no need to plan for the current one-kernel-per-board case.
We were absolutely banking on targeting the results of this work, so that's good ;-)
Ian.