This patchset adds a new function cpu_generic_new() which is similar to cpu_generic_init() except that it does not realize the created CPU object. This means that board code can do a "new cpu; set QOM properties; realize" sequence without having to do all the work of splitting the CPU model string and calling parse_features by hand.
Patch 2 clarifies a TODO comment, hopefully correctly, based on an email conversation I had with Eduardo a little while back. Patches 3 and 4 change the ARM boards which currently call parse_features by hand to use the new function. If there's consensus that this is the right general direction to go in, then I think that some other architectures could also make cleanups to use this: * cpu_s390x_create() is almost exactly this function, give or take some fine detail of error handling * ppc_cpu_parse_features is almost the same thing, except that it doesn't actually create the CPU object, it only calls parse_features * hw/i386/pc.c does a manual parse_features I'm not strongly attached to this particular approach (though it seems like a reasonable one, especially given the proliferation of different arch-specific helpers listed above and the bugs in boards which don't call parse_features when they should), but I would like us to figure out and document what the right way for a board to create and configure its CPU objects is... Michael Davidsaver (1): cpu: add cpu_generic_new() Peter Maydell (3): cpu: Clarify TODO comment in cpu_generic_new() hw/arm/integrator: Use new cpu_generic_new() hw/arm/virt: Use new cpu_generic_new() include/qom/cpu.h | 17 +++++++++++++++++ hw/arm/integratorcp.c | 22 ++-------------------- hw/arm/virt.c | 24 ++---------------------- qom/cpu.c | 37 ++++++++++++++++++++++++++----------- 4 files changed, 47 insertions(+), 53 deletions(-) -- 2.7.4
