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
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.