On Tue, Jun 13, 2017 at 09:14:55AM +0200, Greg Kurz wrote: > On Mon, 12 Jun 2017 22:15:46 +0800 > David Gibson <da...@gibson.dropbear.id.au> wrote: > > > On Thu, Jun 08, 2017 at 03:43:18PM +0200, Greg Kurz wrote: > > > The ICPState objects are currently registered to vmstate as qdev objects. > > > Their instance ids are hence computed automatically in the migration code, > > > and thus depends on the order the CPU cores were plugged. > > > > > > If the destination had its CPU cores plugged in a different order than the > > > source, then ICPState objects will have different instance_ids and load > > > the wrong state. > > > > > > Since CPU objects have a reliable cpu_index which is already used as > > > instance_id in vmstate, let's use it for ICPState as well. > > > > > > Signed-off-by: Greg Kurz <gr...@kaod.org> > > > > This is certainly an improvement. You answered my query on the > > previous version as to why this doesn't break migration, but that > > information should go into the commit message. > > > > I'll add this explanation to the changelog. > > > So, ideally, we would use the XICS "server number" as the migration > > key. That's an architected part of the XICs state, since those values > > are entered explicitly into the ICS. We have a way to go from server > > number to ICP at the moment, but not the reverse, but we can fix that. > > > > Unfortunately I think those won't always match existing automatically > > generated IDs, which makes things harder. > > > > Maybe things will get better when cpu_dt_id can be contiguous: > > http://www.spinics.net/lists/kvm/msg150390.html > > But I guess it won't help with existing machine types.
Right.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
