[8/9] hw/arm/bcm2836: Hardcode correct CPU type

Message ID 20180313153458.26822-9-peter.maydell@linaro.org
State Superseded
Headers show
Series
  • raspi3: various fixes for Linux booting
Related show

Commit Message

Peter Maydell March 13, 2018, 3:34 p.m.
Now we have separate types for BCM2386 and BCM2387, we might as well
just hard-code the CPU type they use rather than having it passed
through as an object property. This then lets us put the initialization
of the CPU object in init rather than realize.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

---
 hw/arm/bcm2836.c | 22 +++++++++++++---------
 hw/arm/raspi.c   |  2 --
 2 files changed, 13 insertions(+), 11 deletions(-)

-- 
2.16.2

Comments

Andrew Baumann March 13, 2018, 4:55 p.m. | #1
> From: Qemu-devel <qemu-devel-

> bounces+andrew.baumann=microsoft.com@nongnu.org> On Behalf Of Peter

> Maydell

> Sent: Tuesday, 13 March 2018 08:35

> 

> Now we have separate types for BCM2386 and BCM2387, we might as well

> just hard-code the CPU type they use rather than having it passed

> through as an object property. This then lets us put the initialization

> of the CPU object in init rather than realize.

> 

> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

> ---

>  hw/arm/bcm2836.c | 22 +++++++++++++---------

>  hw/arm/raspi.c   |  2 --

>  2 files changed, 13 insertions(+), 11 deletions(-)

> 

> diff --git a/hw/arm/bcm2836.c b/hw/arm/bcm2836.c

> index 7140257c98..12f75b55a7 100644

> --- a/hw/arm/bcm2836.c

> +++ b/hw/arm/bcm2836.c

> @@ -25,16 +25,19 @@

> 

>  struct BCM283XInfo {

>      const char *name;

> +    const char *cpu_type;

>      int clusterid;

>  };

> 

>  static const BCM283XInfo bcm283x_socs[] = {

>      {

>          .name = TYPE_BCM2836,

> +        .cpu_type = ARM_CPU_TYPE_NAME("cortex-a15"),


At some point I remember seeing a patch to change this to cortex-a7. Is there a reason we didn't make that change?

(Background: the real Pi2 has an A7. When I first implemented the machine model there was no A7 emulation in QEMU, so I used the A15 which was the closest equivalent.)

>          .clusterid = 0xf,

>      },

>      {

>          .name = TYPE_BCM2837,

> +        .cpu_type = ARM_CPU_TYPE_NAME("cortex-a53"),

>          .clusterid = 0x0,

>      },

>  };

> @@ -42,6 +45,16 @@ static const BCM283XInfo bcm283x_socs[] = {

>  static void bcm2836_init(Object *obj)

>  {

>      BCM283XState *s = BCM283X(obj);

> +    BCM283XClass *bc = BCM283X_GET_CLASS(obj);

> +    const BCM283XInfo *info = bc->info;

> +    int n;

> +

> +    for (n = 0; n < BCM283X_NCPUS; n++) {

> +        object_initialize(&s->cpus[n], sizeof(s->cpus[n]),

> +                          info->cpu_type);

> +        object_property_add_child(obj, "cpu[*]", OBJECT(&s->cpus[n]),

> +                                  &error_abort);

> +    }

> 

>      object_initialize(&s->control, sizeof(s->control), TYPE_BCM2836_CONTROL);

>      object_property_add_child(obj, "control", OBJECT(&s->control), NULL);

> @@ -69,14 +82,6 @@ static void bcm2836_realize(DeviceState *dev, Error

> **errp)

> 

>      /* common peripherals from bcm2835 */

> 

> -    obj = OBJECT(dev);

> -    for (n = 0; n < BCM283X_NCPUS; n++) {

> -        object_initialize(&s->cpus[n], sizeof(s->cpus[n]),

> -                          s->cpu_type);

> -        object_property_add_child(obj, "cpu[*]", OBJECT(&s->cpus[n]),

> -                                  &error_abort);

> -    }

> -

>      obj = object_property_get_link(OBJECT(dev), "ram", &err);

>      if (obj == NULL) {

>          error_setg(errp, "%s: required ram link not found: %s",

> @@ -168,7 +173,6 @@ static void bcm2836_realize(DeviceState *dev, Error

> **errp)

>  }

> 

>  static Property bcm2836_props[] = {

> -    DEFINE_PROP_STRING("cpu-type", BCM283XState, cpu_type),

>      DEFINE_PROP_UINT32("enabled-cpus", BCM283XState, enabled_cpus,

>                         BCM283X_NCPUS),

>      DEFINE_PROP_END_OF_LIST()

> diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c

> index f588720138..ae15997669 100644

> --- a/hw/arm/raspi.c

> +++ b/hw/arm/raspi.c

> @@ -150,8 +150,6 @@ static void raspi_init(MachineState *machine, int

> version)

>      /* Setup the SOC */

>      object_property_add_const_link(OBJECT(&s->soc), "ram", OBJECT(&s->ram),

>                                     &error_abort);

> -    object_property_set_str(OBJECT(&s->soc), machine->cpu_type, "cpu-type",

> -                            &error_abort);

>      object_property_set_int(OBJECT(&s->soc), smp_cpus, "enabled-cpus",

>                              &error_abort);

>      int board_rev = version == 3 ? 0xa02082 : 0xa21041;


What about the default_cpu_type field of MachineClass set in raspi[23]_machine_init? That seems irrelevant now... Also, if anyone cares (I don't), we also just lost the ability to override the CPU type of a raspi model. 

Otherwise,
Reviewed-by: Andrew Baumann <Andrew.Baumann@microsoft.com>


Cheers,
Andrew
Peter Maydell March 13, 2018, 5:09 p.m. | #2
On 13 March 2018 at 16:55, Andrew Baumann <Andrew.Baumann@microsoft.com> wrote:
>> From: Qemu-devel <qemu-devel-

>> bounces+andrew.baumann=microsoft.com@nongnu.org> On Behalf Of Peter

>> Maydell

>> Sent: Tuesday, 13 March 2018 08:35

>>

>> Now we have separate types for BCM2386 and BCM2387, we might as well

>> just hard-code the CPU type they use rather than having it passed

>> through as an object property. This then lets us put the initialization

>> of the CPU object in init rather than realize.

>>

>> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


>>  static const BCM283XInfo bcm283x_socs[] = {

>>      {

>>          .name = TYPE_BCM2836,

>> +        .cpu_type = ARM_CPU_TYPE_NAME("cortex-a15"),

>

> At some point I remember seeing a patch to change this to cortex-a7. Is there a reason we didn't make that change?

>

> (Background: the real Pi2 has an A7. When I first implemented the machine model there was no A7 emulation in QEMU, so I used the A15 which was the closest equivalent.)


Yeah, we should do that. I'd forgotten about that, I think
things just got lost in the shuffle of having several
patchsets that tried to change the same things at once.

I guess the simplest thing is to add a patch at the end of
the series that fixes the cpu type for bcm2836.


>> --- a/hw/arm/raspi.c

>> +++ b/hw/arm/raspi.c

>> @@ -150,8 +150,6 @@ static void raspi_init(MachineState *machine, int

>> version)

>>      /* Setup the SOC */

>>      object_property_add_const_link(OBJECT(&s->soc), "ram", OBJECT(&s->ram),

>>                                     &error_abort);

>> -    object_property_set_str(OBJECT(&s->soc), machine->cpu_type, "cpu-type",

>> -                            &error_abort);

>>      object_property_set_int(OBJECT(&s->soc), smp_cpus, "enabled-cpus",

>>                              &error_abort);

>>      int board_rev = version == 3 ? 0xa02082 : 0xa21041;

>

> What about the default_cpu_type field of MachineClass set in

> raspi[23]_machine_init? That seems irrelevant now...


Mmm. It doesn't hurt anything, though.

> Also, if anyone cares (I don't), we also just lost the ability

> to override the CPU type of a raspi model.


Yeah, that's deliberate -- I think that letting the user randomly
plug nonexistent combinations together just confuses people when
they don't work. I guess I should call it out in the commit message
though.

thanks
-- PMM
Philippe Mathieu-Daudé March 13, 2018, 11:06 p.m. | #3
On 03/13/2018 04:34 PM, Peter Maydell wrote:
> Now we have separate types for BCM2386 and BCM2387, we might as well

> just hard-code the CPU type they use rather than having it passed

> through as an object property. This then lets us put the initialization

> of the CPU object in init rather than realize.

> 

> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>


> ---

>  hw/arm/bcm2836.c | 22 +++++++++++++---------

>  hw/arm/raspi.c   |  2 --

>  2 files changed, 13 insertions(+), 11 deletions(-)

> 

> diff --git a/hw/arm/bcm2836.c b/hw/arm/bcm2836.c

> index 7140257c98..12f75b55a7 100644

> --- a/hw/arm/bcm2836.c

> +++ b/hw/arm/bcm2836.c

> @@ -25,16 +25,19 @@

>  

>  struct BCM283XInfo {

>      const char *name;

> +    const char *cpu_type;

>      int clusterid;

>  };

>  

>  static const BCM283XInfo bcm283x_socs[] = {

>      {

>          .name = TYPE_BCM2836,

> +        .cpu_type = ARM_CPU_TYPE_NAME("cortex-a15"),

>          .clusterid = 0xf,

>      },

>      {

>          .name = TYPE_BCM2837,

> +        .cpu_type = ARM_CPU_TYPE_NAME("cortex-a53"),

>          .clusterid = 0x0,

>      },

>  };

> @@ -42,6 +45,16 @@ static const BCM283XInfo bcm283x_socs[] = {

>  static void bcm2836_init(Object *obj)

>  {

>      BCM283XState *s = BCM283X(obj);

> +    BCM283XClass *bc = BCM283X_GET_CLASS(obj);

> +    const BCM283XInfo *info = bc->info;

> +    int n;

> +

> +    for (n = 0; n < BCM283X_NCPUS; n++) {

> +        object_initialize(&s->cpus[n], sizeof(s->cpus[n]),

> +                          info->cpu_type);

> +        object_property_add_child(obj, "cpu[*]", OBJECT(&s->cpus[n]),

> +                                  &error_abort);

> +    }

>  

>      object_initialize(&s->control, sizeof(s->control), TYPE_BCM2836_CONTROL);

>      object_property_add_child(obj, "control", OBJECT(&s->control), NULL);

> @@ -69,14 +82,6 @@ static void bcm2836_realize(DeviceState *dev, Error **errp)

>  

>      /* common peripherals from bcm2835 */

>  

> -    obj = OBJECT(dev);

> -    for (n = 0; n < BCM283X_NCPUS; n++) {

> -        object_initialize(&s->cpus[n], sizeof(s->cpus[n]),

> -                          s->cpu_type);

> -        object_property_add_child(obj, "cpu[*]", OBJECT(&s->cpus[n]),

> -                                  &error_abort);

> -    }

> -

>      obj = object_property_get_link(OBJECT(dev), "ram", &err);

>      if (obj == NULL) {

>          error_setg(errp, "%s: required ram link not found: %s",

> @@ -168,7 +173,6 @@ static void bcm2836_realize(DeviceState *dev, Error **errp)

>  }

>  

>  static Property bcm2836_props[] = {

> -    DEFINE_PROP_STRING("cpu-type", BCM283XState, cpu_type),

>      DEFINE_PROP_UINT32("enabled-cpus", BCM283XState, enabled_cpus,

>                         BCM283X_NCPUS),

>      DEFINE_PROP_END_OF_LIST()

> diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c

> index f588720138..ae15997669 100644

> --- a/hw/arm/raspi.c

> +++ b/hw/arm/raspi.c

> @@ -150,8 +150,6 @@ static void raspi_init(MachineState *machine, int version)

>      /* Setup the SOC */

>      object_property_add_const_link(OBJECT(&s->soc), "ram", OBJECT(&s->ram),

>                                     &error_abort);

> -    object_property_set_str(OBJECT(&s->soc), machine->cpu_type, "cpu-type",

> -                            &error_abort);

>      object_property_set_int(OBJECT(&s->soc), smp_cpus, "enabled-cpus",

>                              &error_abort);

>      int board_rev = version == 3 ? 0xa02082 : 0xa21041;

>
Philippe Mathieu-Daudé March 13, 2018, 11:16 p.m. | #4
On 03/13/2018 06:09 PM, Peter Maydell wrote:
> On 13 March 2018 at 16:55, Andrew Baumann <Andrew.Baumann@microsoft.com> wrote:

>>> From: Qemu-devel <qemu-devel-

>>> bounces+andrew.baumann=microsoft.com@nongnu.org> On Behalf Of Peter

>>> Maydell

>>> Sent: Tuesday, 13 March 2018 08:35

>>>

>>> Now we have separate types for BCM2386 and BCM2387, we might as well

>>> just hard-code the CPU type they use rather than having it passed

>>> through as an object property. This then lets us put the initialization

>>> of the CPU object in init rather than realize.

>>>

>>> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

> 

>>>  static const BCM283XInfo bcm283x_socs[] = {

>>>      {

>>>          .name = TYPE_BCM2836,

>>> +        .cpu_type = ARM_CPU_TYPE_NAME("cortex-a15"),

>>

>> At some point I remember seeing a patch to change this to cortex-a7. Is there a reason we didn't make that change?

>>

>> (Background: the real Pi2 has an A7. When I first implemented the machine model there was no A7 emulation in QEMU, so I used the A15 which was the closest equivalent.)

> 

> Yeah, we should do that. I'd forgotten about that, I think

> things just got lost in the shuffle of having several

> patchsets that tried to change the same things at once.

> 

> I guess the simplest thing is to add a patch at the end of

> the series that fixes the cpu type for bcm2836.


Peter, here is the patch Andrew remembered (maybe can be applied at the
end):
http://lists.nongnu.org/archive/html/qemu-devel/2018-02/msg04286.html

> 

> 

>>> --- a/hw/arm/raspi.c

>>> +++ b/hw/arm/raspi.c

>>> @@ -150,8 +150,6 @@ static void raspi_init(MachineState *machine, int

>>> version)

>>>      /* Setup the SOC */

>>>      object_property_add_const_link(OBJECT(&s->soc), "ram", OBJECT(&s->ram),

>>>                                     &error_abort);

>>> -    object_property_set_str(OBJECT(&s->soc), machine->cpu_type, "cpu-type",

>>> -                            &error_abort);

>>>      object_property_set_int(OBJECT(&s->soc), smp_cpus, "enabled-cpus",

>>>                              &error_abort);

>>>      int board_rev = version == 3 ? 0xa02082 : 0xa21041;

>>

>> What about the default_cpu_type field of MachineClass set in

>> raspi[23]_machine_init? That seems irrelevant now...

> 

> Mmm. It doesn't hurt anything, though.

> 

>> Also, if anyone cares (I don't), we also just lost the ability

>> to override the CPU type of a raspi model.

> 

> Yeah, that's deliberate -- I think that letting the user randomly

> plug nonexistent combinations together just confuses people when

> they don't work. I guess I should call it out in the commit message

> though.

> 

> thanks

> -- PMM

>
Philippe Mathieu-Daudé March 13, 2018, 11:16 p.m. | #5
On 03/13/2018 06:09 PM, Peter Maydell wrote:
> On 13 March 2018 at 16:55, Andrew Baumann <Andrew.Baumann@microsoft.com> wrote:

>>> From: Qemu-devel <qemu-devel-

>>> bounces+andrew.baumann=microsoft.com@nongnu.org> On Behalf Of Peter

>>> Maydell

>>> Sent: Tuesday, 13 March 2018 08:35

>>>

>>> Now we have separate types for BCM2386 and BCM2387, we might as well

>>> just hard-code the CPU type they use rather than having it passed

>>> through as an object property. This then lets us put the initialization

>>> of the CPU object in init rather than realize.

>>>

>>> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

> 

>>>  static const BCM283XInfo bcm283x_socs[] = {

>>>      {

>>>          .name = TYPE_BCM2836,

>>> +        .cpu_type = ARM_CPU_TYPE_NAME("cortex-a15"),

>>

>> At some point I remember seeing a patch to change this to cortex-a7. Is there a reason we didn't make that change?

>>

>> (Background: the real Pi2 has an A7. When I first implemented the machine model there was no A7 emulation in QEMU, so I used the A15 which was the closest equivalent.)

> 

> Yeah, we should do that. I'd forgotten about that, I think

> things just got lost in the shuffle of having several

> patchsets that tried to change the same things at once.

> 

> I guess the simplest thing is to add a patch at the end of

> the series that fixes the cpu type for bcm2836.


Peter, here is the patch Andrew remembered (maybe can be applied at the
end):
http://lists.nongnu.org/archive/html/qemu-devel/2018-02/msg04286.html

> 

> 

>>> --- a/hw/arm/raspi.c

>>> +++ b/hw/arm/raspi.c

>>> @@ -150,8 +150,6 @@ static void raspi_init(MachineState *machine, int

>>> version)

>>>      /* Setup the SOC */

>>>      object_property_add_const_link(OBJECT(&s->soc), "ram", OBJECT(&s->ram),

>>>                                     &error_abort);

>>> -    object_property_set_str(OBJECT(&s->soc), machine->cpu_type, "cpu-type",

>>> -                            &error_abort);

>>>      object_property_set_int(OBJECT(&s->soc), smp_cpus, "enabled-cpus",

>>>                              &error_abort);

>>>      int board_rev = version == 3 ? 0xa02082 : 0xa21041;

>>

>> What about the default_cpu_type field of MachineClass set in

>> raspi[23]_machine_init? That seems irrelevant now...

> 

> Mmm. It doesn't hurt anything, though.

> 

>> Also, if anyone cares (I don't), we also just lost the ability

>> to override the CPU type of a raspi model.

> 

> Yeah, that's deliberate -- I think that letting the user randomly

> plug nonexistent combinations together just confuses people when

> they don't work. I guess I should call it out in the commit message

> though.

> 

> thanks

> -- PMM

>
Peter Maydell March 15, 2018, 5:13 p.m. | #6
On 13 March 2018 at 16:55, Andrew Baumann <Andrew.Baumann@microsoft.com> wrote:
>> From: Qemu-devel <qemu-devel-

>> bounces+andrew.baumann=microsoft.com@nongnu.org> On Behalf Of Peter

>> Maydell

>> Sent: Tuesday, 13 March 2018 08:35

>>

>> Now we have separate types for BCM2386 and BCM2387, we might as well

>> just hard-code the CPU type they use rather than having it passed

>> through as an object property. This then lets us put the initialization

>> of the CPU object in init rather than realize.


> What about the default_cpu_type field of MachineClass set in

> raspi[23]_machine_init? That seems irrelevant now...


Igor, can you help with this question? For a board that always
has one CPU type (because the real hardware only ever has
one SoC, and that SoC QOM object hard codes the CPU type)
does it still need to set the mc->default_cpu_type field in
its MachineClass, or does that become pointless ?

thanks
-- PMM
Peter Maydell March 19, 2018, 10:58 a.m. | #7
On 13 March 2018 at 23:16, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> On 03/13/2018 06:09 PM, Peter Maydell wrote:

>> On 13 March 2018 at 16:55, Andrew Baumann <Andrew.Baumann@microsoft.com> wrote:

>>> At some point I remember seeing a patch to change this to cortex-a7. Is there a reason we didn't make that change?

>>>

>>> (Background: the real Pi2 has an A7. When I first implemented the machine model there was no A7 emulation in QEMU, so I used the A15 which was the closest equivalent.)

>>

>> Yeah, we should do that. I'd forgotten about that, I think

>> things just got lost in the shuffle of having several

>> patchsets that tried to change the same things at once.

>>

>> I guess the simplest thing is to add a patch at the end of

>> the series that fixes the cpu type for bcm2836.

>

> Peter, here is the patch Andrew remembered (maybe can be applied at the

> end):

> http://lists.nongnu.org/archive/html/qemu-devel/2018-02/msg04286.html


Thanks for finding that. It doesn't apply after this refactoring,
but I'll send out a patch which does the equivalent thing in the
new code. In the meantime I'm going to apply this patchset to
target-arm.next since I'm going to send out a pullreq with bugfixes
for rc0 today.

thanks
-- PMM
Peter Maydell March 19, 2018, 11:57 a.m. | #8
On 13 March 2018 at 15:34, Peter Maydell <peter.maydell@linaro.org> wrote:
> Now we have separate types for BCM2386 and BCM2387, we might as well

> just hard-code the CPU type they use rather than having it passed

> through as an object property. This then lets us put the initialization

> of the CPU object in init rather than realize.

>

> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

> ---

>  hw/arm/bcm2836.c | 22 +++++++++++++---------

>  hw/arm/raspi.c   |  2 --

>  2 files changed, 13 insertions(+), 11 deletions(-)

>

> diff --git a/hw/arm/bcm2836.c b/hw/arm/bcm2836.c

> index 7140257c98..12f75b55a7 100644

> --- a/hw/arm/bcm2836.c

> +++ b/hw/arm/bcm2836.c

> @@ -25,16 +25,19 @@

>

>  struct BCM283XInfo {

>      const char *name;

> +    const char *cpu_type;

>      int clusterid;

>  };

>

>  static const BCM283XInfo bcm283x_socs[] = {

>      {

>          .name = TYPE_BCM2836,

> +        .cpu_type = ARM_CPU_TYPE_NAME("cortex-a15"),

>          .clusterid = 0xf,

>      },

>      {

>          .name = TYPE_BCM2837,

> +        .cpu_type = ARM_CPU_TYPE_NAME("cortex-a53"),

>          .clusterid = 0x0,

>      },

>  };


With this change we need to also add
#ifdef TARGET_AARCH64
#endif

around the entry in the array for bcm2837. Otherwise the
device-introspection tests in 'make check' will fail trying
to create the bcm2837 in qemu-system-arm, because there there
is no cortex-a53 device.

I'll just squash that into this patch...

thanks
-- PMM
Igor Mammedov March 19, 2018, 2:40 p.m. | #9
On Thu, 15 Mar 2018 17:13:03 +0000
Peter Maydell <peter.maydell@linaro.org> wrote:

> On 13 March 2018 at 16:55, Andrew Baumann <Andrew.Baumann@microsoft.com> wrote:

> >> From: Qemu-devel <qemu-devel-

> >> bounces+andrew.baumann=microsoft.com@nongnu.org> On Behalf Of Peter

> >> Maydell

> >> Sent: Tuesday, 13 March 2018 08:35

> >>

> >> Now we have separate types for BCM2386 and BCM2387, we might as well

> >> just hard-code the CPU type they use rather than having it passed

> >> through as an object property. This then lets us put the initialization

> >> of the CPU object in init rather than realize.

> 

> > What about the default_cpu_type field of MachineClass set in

> > raspi[23]_machine_init? That seems irrelevant now...

> 

> Igor, can you help with this question? For a board that always

> has one CPU type (because the real hardware only ever has

> one SoC, and that SoC QOM object hard codes the CPU type)

> does it still need to set the mc->default_cpu_type field in

> its MachineClass, or does that become pointless ?


Since board ignores whatever were specified on '-cpu' and 
there aren't any checks in board code for current_machine->cpu_type,
removing mc->default_cpu_type won't really affect anything.

With current code in vl.c and with default_cpu_type set, user will
get error if he specified non existing cpu_model with -cpu.
If default_cpu_type were NULL, -cpu is completely ignored.

But once http://patchwork.ozlabs.org/patch/870297/ is applied
it will error out the same way as if default_cpu_type were
set since vl.c won't rely on it anymore for parsing cpu_model.

So in short it's ok to remove mc->default_cpu_type here.

> 

> thanks

> -- PMM
Peter Maydell March 19, 2018, 6:25 p.m. | #10
On 19 March 2018 at 14:40, Igor Mammedov <imammedo@redhat.com> wrote:
> On Thu, 15 Mar 2018 17:13:03 +0000

> Peter Maydell <peter.maydell@linaro.org> wrote:

>> Igor, can you help with this question? For a board that always

>> has one CPU type (because the real hardware only ever has

>> one SoC, and that SoC QOM object hard codes the CPU type)

>> does it still need to set the mc->default_cpu_type field in

>> its MachineClass, or does that become pointless ?

>

> Since board ignores whatever were specified on '-cpu' and

> there aren't any checks in board code for current_machine->cpu_type,

> removing mc->default_cpu_type won't really affect anything.

>

> With current code in vl.c and with default_cpu_type set, user will

> get error if he specified non existing cpu_model with -cpu.

> If default_cpu_type were NULL, -cpu is completely ignored.

>

> But once http://patchwork.ozlabs.org/patch/870297/ is applied

> it will error out the same way as if default_cpu_type were

> set since vl.c won't rely on it anymore for parsing cpu_model.

>

> So in short it's ok to remove mc->default_cpu_type here.


Thanks for the explanation. I think what I'll do is put these
in as-is, and then have a followup patch that cleans up the
default_cpu_types from raspi.c once that patch 870297 is in.

-- PMM

Patch

diff --git a/hw/arm/bcm2836.c b/hw/arm/bcm2836.c
index 7140257c98..12f75b55a7 100644
--- a/hw/arm/bcm2836.c
+++ b/hw/arm/bcm2836.c
@@ -25,16 +25,19 @@ 
 
 struct BCM283XInfo {
     const char *name;
+    const char *cpu_type;
     int clusterid;
 };
 
 static const BCM283XInfo bcm283x_socs[] = {
     {
         .name = TYPE_BCM2836,
+        .cpu_type = ARM_CPU_TYPE_NAME("cortex-a15"),
         .clusterid = 0xf,
     },
     {
         .name = TYPE_BCM2837,
+        .cpu_type = ARM_CPU_TYPE_NAME("cortex-a53"),
         .clusterid = 0x0,
     },
 };
@@ -42,6 +45,16 @@  static const BCM283XInfo bcm283x_socs[] = {
 static void bcm2836_init(Object *obj)
 {
     BCM283XState *s = BCM283X(obj);
+    BCM283XClass *bc = BCM283X_GET_CLASS(obj);
+    const BCM283XInfo *info = bc->info;
+    int n;
+
+    for (n = 0; n < BCM283X_NCPUS; n++) {
+        object_initialize(&s->cpus[n], sizeof(s->cpus[n]),
+                          info->cpu_type);
+        object_property_add_child(obj, "cpu[*]", OBJECT(&s->cpus[n]),
+                                  &error_abort);
+    }
 
     object_initialize(&s->control, sizeof(s->control), TYPE_BCM2836_CONTROL);
     object_property_add_child(obj, "control", OBJECT(&s->control), NULL);
@@ -69,14 +82,6 @@  static void bcm2836_realize(DeviceState *dev, Error **errp)
 
     /* common peripherals from bcm2835 */
 
-    obj = OBJECT(dev);
-    for (n = 0; n < BCM283X_NCPUS; n++) {
-        object_initialize(&s->cpus[n], sizeof(s->cpus[n]),
-                          s->cpu_type);
-        object_property_add_child(obj, "cpu[*]", OBJECT(&s->cpus[n]),
-                                  &error_abort);
-    }
-
     obj = object_property_get_link(OBJECT(dev), "ram", &err);
     if (obj == NULL) {
         error_setg(errp, "%s: required ram link not found: %s",
@@ -168,7 +173,6 @@  static void bcm2836_realize(DeviceState *dev, Error **errp)
 }
 
 static Property bcm2836_props[] = {
-    DEFINE_PROP_STRING("cpu-type", BCM283XState, cpu_type),
     DEFINE_PROP_UINT32("enabled-cpus", BCM283XState, enabled_cpus,
                        BCM283X_NCPUS),
     DEFINE_PROP_END_OF_LIST()
diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index f588720138..ae15997669 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -150,8 +150,6 @@  static void raspi_init(MachineState *machine, int version)
     /* Setup the SOC */
     object_property_add_const_link(OBJECT(&s->soc), "ram", OBJECT(&s->ram),
                                    &error_abort);
-    object_property_set_str(OBJECT(&s->soc), machine->cpu_type, "cpu-type",
-                            &error_abort);
     object_property_set_int(OBJECT(&s->soc), smp_cpus, "enabled-cpus",
                             &error_abort);
     int board_rev = version == 3 ? 0xa02082 : 0xa21041;