On Tue, Oct 18, 2016 at 07:12:51PM +0100, Peter Maydell wrote: > 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 > nr_sockets/nr_cores/etc scheme.
I am confused now. I thought QOM properties were meant for user-visible and/or user-configurable data. I assumed that if it's only meant to be used by C code inside QEMU, C functions and/or C struct fields were the way to go. See a previous thread where this was discussed: https://www.mail-archive.com/qemu-devel@nongnu.org/msg387169.html (Subject: "QOM: best way for parents to pass information to children?") > > > 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. If it doesn't make sense to let the user mess with it, why would we make it a QOM property? -- Eduardo
