A high level try at KVM for ARM
peter.maydell at linaro.org
Mon Jan 9 21:53:09 UTC 2012
On 9 January 2012 20:30, Michael Hope <michael.hope at linaro.org> wrote:
> On Tue, Jan 10, 2012 at 4:07 AM, Peter Maydell <peter.maydell at 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.
More information about the linaro-toolchain