On 18 October 2016 at 18:57, Andrew Jones <drjo...@redhat.com> wrote:
> On Tue, Oct 18, 2016 at 06:07:49PM +0100, Peter Maydell wrote:
>> Why do you want to un-property mp_affinity? Eventually it would
>> be nice for the machine model to be able to use it to set up
>> a specific NUMA configuration.
> I thought about that, but I think we'll want to specify machine
> properties; nr_sockets, nr_cores, nr_threads and use the -device
> command line for the cpu to specify which socket, which core,
> which thread it is. This would be consistent with other architectures
> and easily map to the MPIDR & cpu topology hardware descriptions.
I was thinking more about "modelling board X, which we know
always has 2xA53 and 4xA57 with these MPIDRs".
We actually have a concrete instance in the tree at the moment:
the raspberry pi 2. Specifically hw/arm/bcm2836.c sets the
mp_affinity for each cpu to 0xF00 | n (where n is the CPUID).
Currently it's doing that by reaching in and messing with
the mp_affinity field directly, but really it ought to be
doing it by setting a property on the CPU, and what it
wants isn't somethnig that can be expressed with a simple
> Anyway, atm, I don't know of any reason to have the property user-
> settable, so it seems safest to keep it hidden until we decide.
I agree that it doesn't make sense to let the user mess with it,
but it should be available for the board code to read and write.