Re: [Qemu-ppc] [Qemu-devel] [PATCH v3 2/3] exec: rename cpu_exec_init() as cpu_exec_realizefn()

[Andrew Jones]

On Tue, Oct 18, 2016 at 06:07:49PM +0100, Peter Maydell wrote:
> On 18 October 2016 at 17:22, Andrew Jones <address@hidden> wrote:
> > I'll note that it's
> > accepted to reach into machine state through current_machine from
> > the machine's devices.
> 
> That doesn't sound like a great idea to me -- where do we
> do it? A quick grep for uses of current_machine in hw/ shows only
> hw/ppc/spapr_rtas.c, which is a bit of a weirdo thing because
> it's the implementation of a bunch of hypercalls, not an actual
> device.
> 
> We have lots of code currently in devices that looks at bits
> of overall state that it should ideally not (but which it can
> because we have a lot of global variables). In an ideal world
> we'd clean these up so that the devices were initialized with
> suitable properties instead to tell them about this global state.
> 
> >> > I considered that, but if we un-property ARMCPU->mp_affinity, then where
> >> > can it be initialized to "MP_AFFINITY_INVALID", which would be ff000000?
> >>
> >> Property defaults are normally initialized on instance_init.
> >
> > OK, so after this series goes through we can un-property mp_affinity and
> > add an mp_affinity initialization back to arm_cpu_initfn, but one that
> > only sets the initial invalid value.
> 
> Note that mp_affinity is a bit awkward because for KVM we can't
> get the right values out of the kernel until quite late (when
> kvm_init_vcpu() is called).
> 
> 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.
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.

Thanks,
drew