On 18 October 2016 at 17:22, Andrew Jones <drjo...@redhat.com> 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. thanks -- PMM
