On Mon, 26 Jun 2017 23:33:48 -0300 Eduardo Habkost <ehabk...@redhat.com> wrote:
> On Mon, Jun 26, 2017 at 02:28:13PM +0100, Alex Bennée wrote: > > > > Peter Maydell <peter.mayd...@linaro.org> writes: > > > > > 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. > > > > > > Just going through my review queue and I see this needs re-basing. Is > > there going to be another rev or was a different approach suggested? > > The right way to go is not clear. We know we want to remove duplication > of CPU creation code, but probably we should first refactor the -cpu > parsing code, so parsing happens: 1) only once; 2) earlier in main(), > preferably before machine->init() runs; 3) inside generic code instead > of arch-specific code; 4) preferably using the QemuOpts parser instead > of the current strtok()-based custom parsers. > > After the parsing code mess is sorted out, writing a generic CPU > creation wrapper will probably be easier (and safer). Also there is legacy cpu features parsing/handling in sparc target, so we might need to clean it up and convert to property based features (as have been done for i386) before making generic cpu creation.
