On Thu, Oct 08, 2015 at 10:17:09AM +0300, Pavel Fedin wrote: > Hello! > > > + The mpidr encoding is based on the affinity information in the > > + architecture defined MPIDR, and the field is encoded as follows: > > + | 63 .... 56 | 55 .... 48 | 47 .... 40 | 39 .... 32 | > > + | Aff3 | Aff2 | Aff1 | Aff0 | > > One concern about this... Does it already have "We are Bosses, we Decided it, It's not subject to > change, We do not care" status? That's a rather negative question. We spent a fair amount of time discussing this during SFO15 and arrived at the conclusion that this was the way to go. If there are good arguments for why this is not sufficient or causes problems, then of course we'll make changes as required. > Actually, current approach with using index instead of Aff bits > works pretty well. It works fine with qemu too, because internally qemu also maintains CPU index, > which it uses for GICv2 accesses. > Keeping index allows to reuse more code, and provides better backwards compatibility. So could we > do this? > The architecture defines how to address a specific CPU, and that's using the MPIDR, not inventing our own scheme, so that's what we should do. For example, I don't think you had the full 32-bits available to address a CPU in your proposal, so if nothing else, that proposal had less expressive power than what the architecture defines. I also don't buy the argument that this saves a lot of code. If you have something that deals with a cpu index, surely two simple functions can allow the same amount of code reuse: unsigned long mpidr_to_vcpu_idx(unsigned long mpidr); unsigned long vcpu_idx_to_mpidr(unsigned long vcpu_idx); -Christoffer -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
