qemu-devel
[Top][All Lists]
Advanced

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

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


From: Igor Mammedov
Subject: Re: [Qemu-devel] [PATCH 00/24] generalize parsing of cpu_model (part 4)
Date: Wed, 17 Jan 2018 20:15:15 +0100

On Wed, 17 Jan 2018 16:12:09 +0000
Peter Maydell <address@hidden> wrote:

> On 17 January 2018 at 15:43, Igor Mammedov <address@hidden> wrote:
> > Series is finishing work on generalizing cpu_model parsing
> > and limiting parts that deal with inconsistent cpu_model
> > naming to "-cpu" CLI option processing in vl.c/*-user.main.c
> > and FOO_cpu_class_by_name() callbacks.
> >
> > It introduces TARGET_DEFAULT_CPU_TYPE which must be defined
> > by each target and is used setting default cpu type for
> > linux/bsd-user targets and as anchor point to pick cpu class
> > that provides target specific FOO_cpu_class_by_name()
> > callback for cpu_parse_cpu_model() in null-machine.c
> > which is compiled for all targets that have system
> > mode emulation.  
> 
> 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.
I admit that it's a convoluted API i.e. for cpu_parse_cpu_model()
to require a target specific CPU type to resolve cpu_model name,
but that's what we ended up with and have now.
It seemed logical to me to put YET_ANOTHER_CPU_TYPE to
target/$ARCH/cpu.h along with other target specific CPU type
macros'. 

Main goal of this series is not TARGET_DEFAULT_CPU_TYPE and
its abuse by null-machine.c, but rather getting rid of
cpu_model handling across whole tree (which is easy to misuse
due to existing APIs and its general availability) and limiting
cpu_model translation to option parsing+target specific
cpu_class_by_name() callbacks.

We can build on top of that linux-user specific extension
to pick CPU type based on ELF notes, the difference would
be that it will work with cpu types and not with cpu_model
as it were implemented in:
  [PATCH v3 0/4] linux-user: select CPU type according  ELF header values

> thanks
> -- PMM




reply via email to

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