On Wed, Mar 16, 2016 at 08:11:48AM +1100, Benjamin Herrenschmidt wrote: > On Tue, 2016-03-15 at 20:45 +1100, David Gibson wrote: > > On Mon, Mar 14, 2016 at 05:56:27PM +0100, Cédric Le Goater wrote: > > > > > > From: Benjamin Herrenschmidt <b...@kernel.crashing.org> > > > > > > Also use it to clamp the max SMT mode and ensure that the cpu_dt_id > > > are offset by that value in order to preserve consistency with the > > > HW implementations. > > > I think this can change change CPU ids, and therefore break migration > > on some existing setups. So it will need some rework to apply at > > all, and will certainly want to wait until after 2.6 > > Our migration is so bloody damn fragile ... grrr.
Well, yes, but that can't really be blamed for this one: you're
changing a guest visible detail.
> We will need it for powernv though, there are many things especially in
> OPAL that rely on the consistent numbering.
Right. Really it doesn't make sense to allocate the dt_id here - that
should be done in the machine type code which actually controls the
DT. That way we can change to fixed numbering for powernv (and
possibly future spapr) machine types, while leaving it the same for
existing machine types for compatibility.
> In fact, it will have to go further and number the cores based on their
> equivalent HW numbers at some point for SCOMs to work, which means a
> slightly discontiguous numbering scheme (no core 0 for example). At
> least if we want to model some of the EX XSCOMs.
Right, another argument that the machine setup code needs to be in
charge of the guest visible CPU ids.
--
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
