On Fri, Feb 17, 2017 at 07:56:32PM +0100, Igor Mammedov 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. > > PS: > As I don't have time to rewrite this part QEMU, being busy > rewritting yet another part of QEMU, > SERIES IS UNFINISHED AND SERVERS TO SHOW IDEA HOW IT SHOULD > BE DONE. FEEL FREE TO PICK UP AND COMPLETE THIS PATCHES > TO HANDLE ALL BOARDS (series does it only for virt-arm/spapr/pc) > > It compiles and pc machine even starts but otherwise is untested.
The approach makes sense to me, but I haven't reviewed all the code yet. That said, I don't think this excludes the possiblity of adding a temporary cpu_generic_new() wrapper in case it is useful in the meantime. After this series is applied, cpu_generic_new() could be automatically replaced by object_new(machine->cpu_typename). Peter, do you think a wrapper for parse_features + object_new() would still be necessary to avoid too much code duplication on arm boards in 2.9, or can we live without it until we apply Igor's series (probaly after 2.9)? -- Eduardo
