Re: [Qemu-devel] [PATCH 00/24] generalize parsing of cpu_model (part 4)

[Igor Mammedov]

On Wed, 17 Jan 2018 20:30:14 +0000
Peter Maydell <address@hidden> wrote:

> On 17 January 2018 at 19:15, Igor Mammedov <address@hidden> wrote:
> > On Wed, 17 Jan 2018 16:12:09 +0000
> > Peter Maydell <address@hidden> wrote:  
> >> I like moving this from being an ifdef ladder into per-cpu
> >> code, but I don't think the definition belongs in target/$ARCH.
> >> It's part of the choice usermode makes about how to handle
> >> binaries it's loading, so it should go in linux-user/$ARCH/target_cpu.h.
> >> target/$ARCH should really be for things that are properties
> >> of the architecture.  
> > That's used not only by linux-user but also reused by null-machine.c
> > to get access to a target specific cpu_class_by_name() callback.  
> 
> That usage must want a different name, though, surely?
> For Arm the default CPU for linux-user is 'any' but that
> is usermode only and won't work for system emulation so
> null-machine.c will need to pick something else.
not really in general as boards set their own default types
and secondly it applies only to null-machine.
Though in both cases it work the same just fine because
current API works like this (system emulation)
 vl.c:
        current_machine->cpu_type = machine_class->default_cpu_type;            
 
        if (cpu_model) {                                                        
 
            current_machine->cpu_type =                                         
 
                cpu_parse_cpu_model(machine_class->default_cpu_type, 
cpu_model); 
            ...
        }

which would result for null-machine (patch 20/24) in:

       cpu_parse_cpu_model(TARGET_DEFAULT_CPU_TYPE, cpu_model):
            oc = cpu_class_by_name(TARGET_DEFAULT_CPU_TYPE, cpu_model):
                 cc = CPU_CLASS(object_class_by_name(TARGET_DEFAULT_CPU_TYPE))
                 cc->class_by_name(cpu_model)
            
so it doesn't really matter for system emulation what exact
type is used as a proxy to reach callback, as each target
implements only one cb in base CPU class and any leaf class
will work fine to reach the same class_by_name() cb.
So type that is default for linux-user can be abused for
this purpose and could be used as linux-default at
the same time.

Ugly and hackish, yes.
But it isolates cpu_model handling to a few places and
series removes API that uses it, so we won't have to
watch out for patches that would bring cpu_model
back into boards code after that.

On top of that, we could work on making cpu_parse_cpu_model()
API not to require proxy cpu type and that would affect
only 3 remaining callers in vl.c,bsd/linux-user/main.c
But that another re-factoring beyond the scope of this series,
which is already big as it is.

> thanks
> -- PMM