On 17 February 2017 at 18:56, Igor Mammedov <imamm...@redhat.com> wrote: > Some callers call CPUClass->parse_features manually to convert > '-cpu cpufoo,featurestr' string to cpu type and featurestr > into a set of global properties. And theni do controlled > cpu creation with setting properties and completing it with realize. > That's a lot of code duplication as they are practically > reimplement the same parsing logic. > > Some don't and use cpu_generic_init() instead which does > the same parsing along with creation/realizing cpu within one > wrapper. > > And some trying to switch to controlled cpu creation, > implement object_new()/set properties/realize steps > but forget feature parsing logic witch lieads to 'bugs' > commit 00909b585 (hw/arm/integratorcp: Support specifying features via -cpu) > > > This series moves -cpu option parsing to generic machine code > that removes a little of code duplication and makes cpus creation > process more unified.
This API seems a little awkward for the SoC case, where the board model doesn't actually know what the default CPU model or the valid CPU models are, because it just wants to say "create me a BCM2836 SoC" and let the SoC object deal with determining whether it's always a cortex-a15 or if it might allow some user configurability either in cpu choices or in optional flags. Any thoughts about that use case? (The stm32f205 SoC object has a "cpu-model" QOM property that the board sets, but I think that's as much because we somewhat awkwardly need to pass it into armv7m_init() as a deliberate design choice.) thanks -- PMM