I've taken a stab at the medium term requirements for KVM on ARM: https://wiki.linaro.org/WorkingGroups/ToolChain/Specs/KVMEpic
I haven't looked outside Linaro so apologies if this overlaps with other people's plans.
Peter, this is high level and hopefully matches what's in your head. I want to use this to do a project plan, see if it can be done in 6-9 calendar months, and see if we need more people. Are there any implementation details that we should call out, similar to calling out virtio and UEFI?
Rusty, this should tell you more about where we're going.
Mounir, you, Peter, and I should turn this into a basic project plan.
-- Michael
On 9 January 2012 02:36, Michael Hope michael.hope@linaro.org wrote:
I've taken a stab at the medium term requirements for KVM on ARM: https://wiki.linaro.org/WorkingGroups/ToolChain/Specs/KVMEpic
I've marked this up with my initial comments.
-- PMM
On Tue, Jan 10, 2012 at 4:07 AM, Peter Maydell peter.maydell@linaro.org wrote:
On 9 January 2012 02:36, Michael Hope michael.hope@linaro.org wrote:
I've taken a stab at the medium term requirements for KVM on ARM: https://wiki.linaro.org/WorkingGroups/ToolChain/Specs/KVMEpic
I've marked this up with my initial comments.
Added replies which are:
"virtio over AMBA" still requires some model, so presumably we'll still be using vexpress. Also we're calling it "virtio-mmio" now (since it's not really AMBA specific).
Changed to virtio-mmio and was explicit about it being vexpress+virtio
I can see why this para is here, but I think we should be aiming to keep the changes required to the guest (kernel config or boot loader arrangements) as minimal as possible.
Agreed. I've added 'minimised' and 'eliminate if reasonable'. One less thing is good.
I realised recently that we could probably model the vexpress compact flash adaptor relatively cheaply which then gives you something that looks like an IDE disk and avoids the performance problems of SD card emulation. Need to check this.
If it's really cheap (~2 days) then yes, otherwise virtio first.
I suspect we want LPAE guests in 1.0.
I'd rather have LPAE in a 1.1 so we can get 1.0 to people and get feedback on it. We can call these 0.9/1.0 instead if need be.
Migration: between-same-version migration should be straightforward enough (there are only a few bits missing). Cross-qemu-version migration is harder as it requires that we pay much more attention to avoiding migration structure version bumps and also to providing back-compat versions of board models (like the x86 "pc-0.14", "pc-0.15" etc) so you can make newer qemu versions act like old ones. I would prefer not to commit to this too early.
won't there only be one model at the first release? Providing it's tagged as vexpress-1.0 and fails if you try to load a later version, is that enough?
is "KSM" Kernel SamePage Merging?
Yes, updated
-- Michael
On 9 January 2012 20:30, Michael Hope michael.hope@linaro.org wrote:
On Tue, Jan 10, 2012 at 4:07 AM, Peter Maydell peter.maydell@linaro.org wrote:
I suspect we want LPAE guests in 1.0.
I'd rather have LPAE in a 1.1 so we can get 1.0 to people and get feedback on it. We can call these 0.9/1.0 instead if need be.
I think it will depend what the 'standard' kernel config is for A15 systems -- it's unlikely that you'll be able to have a kernel that works for both LPAE and not-LPAE. Also I don't think that (for KVM) it's likely to need any extra code (the h/w should just support both kinds of page table). TCG is a different story but even there I don't think it is much extra work.
Migration: between-same-version migration should be straightforward enough (there are only a few bits missing). Cross-qemu-version migration is harder as it requires that we pay much more attention to avoiding migration structure version bumps and also to providing back-compat versions of board models (like the x86 "pc-0.14", "pc-0.15" etc) so you can make newer qemu versions act like old ones. I would prefer not to commit to this too early.
won't there only be one model at the first release? Providing it's tagged as vexpress-1.0 and fails if you try to load a later version, is that enough?
No, it works the other way around. "foo" is always the 'standard' board model for whichever version of QEMU this is. Every time upstream QEMU releases version X, the development tree gets a new board "foo-X" so that version X+1 supports not just "foo" but also a board "foo-X" meaning "foo as it was when we released QEMU version X". QEMU X+2 has "foo", "foo-X", "foo-X+1", and so on.
So once you commit to doing this then you're imposing on yourself this extra burden for every new QEMU release, and you have to be a lot more careful and add a lot more back-compat code and testing to be sure that all those foo-X for all those old values of X still work for cross-version migration. I don't want to do that until (a) we've had a reasonable chance to see that same-version migration is working properly and the machine state isn't getting new tweaks and bits of state etc all the time and (b) we've determined that people really are going to use vexpress-a15 for their guest machine and not something else and (c) there's a reasonable level of user demand for cross-version migration.
NB that cross-version migration is only really needed for 'live' migration. If you're happy to shut the guest system down and then boot it up on the new QEMU version you don't need it.
-- PMM
linaro-toolchain@lists.linaro.org
-
Michael Hope -
Peter Maydell