[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-arm] QOM properties vs C functions/fields (was Re: [Qemu-devel] [P

From: Eduardo Habkost
Subject: [Qemu-arm] QOM properties vs C functions/fields (was Re: [Qemu-devel] [PATCH v3 2/3] exec: rename cpu_exec_init() as cpu_exec_realizefn())
Date: Tue, 18 Oct 2016 16:45:32 -0200
User-agent: Mutt/1.7.0 (2016-08-17)

On Tue, Oct 18, 2016 at 07:12:51PM +0100, Peter Maydell wrote:
> On 18 October 2016 at 18:57, Andrew Jones <address@hidden> 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:

(Subject: "QOM: best way for parents to pass information to

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]