[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [Qemu-devel] [PATCH 8/9] hw/arm/bcm2836: Hardcode correct

From: Igor Mammedov
Subject: Re: [Qemu-arm] [Qemu-devel] [PATCH 8/9] hw/arm/bcm2836: Hardcode correct CPU type
Date: Mon, 19 Mar 2018 15:40:20 +0100

On Thu, 15 Mar 2018 17:13:03 +0000
Peter Maydell <address@hidden> wrote:

> On 13 March 2018 at 16:55, Andrew Baumann <address@hidden> wrote:
> >> From: Qemu-devel <qemu-devel-
> >> address@hidden> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]