On 1/6/23 13:59, Peter Maydell wrote:
We also set some properties in code -- eg aspeed_ast2600.c clears
the 'neon' property on its CPUs, lots of the boards clear
has_el3 and has_el2, etc.
Yes indeed, but in all of those cases we want all of the cpus to act identically. Those
are all easily handled (patches 35, 36, 38).
I hadn't got as far as patch 29, but
looking at it now that looks like a pretty strong indication
that this is the wrong way to go. It creates 3 extra
cortex-m33 CPU classes, and if we find another thing that
ought to be a CPU property then we'll be up to 8;
If we find another thing that needs to be different between cpus, you mean?
and it becomes visible in user-facing command line stuff.
No it doesn't -- command line is *not* affected, because both before and after, all
properties are applied identically to all objects.
QMP is affected, which is where I stopped and started asking questions about what QMP is
actually trying to do.
I think our object model pretty strongly wants "create object;
set properties on it that only affect this object you created;
realize it", and having one particular subset of objects that
doesn't work the same way is going to be very confusing.
Eh, I didn't think it's particularly confusing as a concept.
The code is rough, buy what one might expect from an RFC.
We really ought to have *some* solution to not repeating property + feature + isar
interpretation on a per-cpu basis. I'd be delighted to hear alternatives.
r~