On Tue, 30 Apr 2013 15:54:34 +0100 Peter Maydell <[email protected]> wrote:
> On 30 April 2013 15:30, Eduardo Habkost <[email protected]> wrote: > > My concern is that we already have a QEMUMachineInitArgs.cpu_model > > field, and now QEMUMachine.cpu_model and QEMUMachineInitArgs.cpu_model > > are redundant. > > > > To make it worse, both variables can disagree with each other because we > > have other code that set QEMUMachineInitArgs.cpu_model outside of > > main(): > > > > hw/arm/realview.c:338: args->cpu_model = "arm926"; > > hw/arm/realview.c:346: args->cpu_model = "arm11mpcore"; > > hw/arm/realview.c:354: args->cpu_model = "cortex-a8"; > > hw/arm/realview.c:362: args->cpu_model = "cortex-a9"; > > hw/arm/versatilepb.c:189: args->cpu_model = "arm926"; > > > > ARM doesn't have CPU hotplug, but this is still a bug waiting to happen. > > This ARM code is just borrowing the cpu_model field as a convenient > place to stash the default value for the board. There are other > ARM boards which do a similar thing but in a purely local variable > (eg vexpress)... yes, patch addresses Eduardo's concern about not setting cpu_model of machine args anywhere else except of main. And later we could cleanup machine args usage and default cpu_models for all targets. > > I think really if you want to know what the current CPU model > is you need to fish the relevant QOM qbject out from somewhere > at runtime. Ideally that QOM object would be QOMifyed QEMUMachine, but we are not there yet. > > -- PMM >
