From: Igor Mammedov <imammedo@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
"patches@linaro.org" <patches@linaro.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>,
qemu-arm <qemu-arm@nongnu.org>,
"qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
Marcel Apfelbaum <marcel@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
David Gibson <david@gibson.dropbear.id.au>,
Stefan Hajnoczi <stefanha@gmail.com>
Subject: Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model
Date: Tue, 21 Feb 2017 13:44:16 +0100 [thread overview]
Message-ID: <20170221134416.5803b3e5@nial.brq.redhat.com> (raw)
In-Reply-To: <CAFEAcA-VAY8LM+8jE4B-L=0QdcY5FLvwmwGVbUhcXjnC9-AW+w@mail.gmail.com>
On Mon, 20 Feb 2017 19:11:00 +0000
Peter Maydell <peter.maydell@linaro.org> wrote:
> On 20 February 2017 at 18:55, Igor Mammedov <imammedo@redhat.com> wrote:
> > Peter Maydell <peter.maydell@linaro.org> wrote:
[...]
>
> > its sole user netduino2 board has cpu_model hardcodded
> > at board level which could be left alone or converted
> > to this API.
>
> I think this may be for the benefit of the not-yet-in-tree
> netduinoplus2 board, which is a very similar SoC but
> with a cortex-m4. There are likely other ways we could
> model that, though.
>
> > Using API would make code more consistent
> > at the cost of more code for default/valid callbacks.
>
> Mmm, we could have the board code just forward the
> default/valid callbacks through to the SoC (which
> would then either implement them or forward them again).
> But I think we should definitely see if we can make
> the code for handling "the CPU is actually inside some
> other object" as clean as we can, because I think
> that's by far the most common case. Machines like
> the x86 pc and the ARM virt board where the CPU is
> instantiated directly in the board code are the
> non-standard cases I think. We have a lot of boards
> where we do instantiate the CPU in the board code
> just for legacy reasons where we don't properly
> model the SoC the CPU is inside. But hardware that
> really has the CPU as a top level pluggable object
> is rare.
If we are to ditch legacy approach,
It would be cleaner for SoC to have fixed/unconfigurable
CPU type and each SoC being modeled as a separate
QOM object/type that would instantiate CPU directly
with QOM style, using type name, like:
cpu = object_new(TYPE_FOO_CPU)
set props if necessary
object_property_set_bool(cpu, true, "realized", &err)
object_unref(cpu)
or similar with extra check/logic on top of plain object_new()
prepare cpu_opts for cpu type TYPE_FOO_CPU
cpu = qdev_device_add(cpu_opts)
object_unref(cpu)
instead of using cpu_init/cpu_foo_init/cpu_generic_init()
with cpu_model parsing logic which is not really needed
there as concrete SoC model knows exact CPU type.
It should work for CPUs that are converted to QOM types,
i.e. a cpu_model maps to a distinct QOM type but we
still have legacy cpu_model handling where we have
not completely QOMifed single base CPU types, ex.
cpu_mips_init(const char *cpu_model)
cpudef = get_feature_set_by_name(cpu+model)
cpu = object_new(TYPE_MIPS_CPU)
cpu->cpudef = cdef
which rely on cpu_model parsing like x86 used to be
before conversion from a single CPU type to a set
of concrete classes. QOMification of remaining
CPUs that rely on legacy cpu_model could be idea
for gsoc/outreachy project so students could learn
about QEMU internals (CCing Stefan).
>
> thanks
> -- PMM
>
next prev parent reply other threads:[~2017-02-21 12:44 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-17 18:56 [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model Igor Mammedov
2017-02-17 18:56 ` [Qemu-devel] [RFC 1/3] machine: call machine init from wrapper Igor Mammedov
2017-02-17 18:56 ` [Qemu-devel] [RFC 2/3] machine: generalize handling of default cpu_model Igor Mammedov
2017-02-17 18:56 ` [Qemu-devel] [RFC 3/3] machine: generilize cpu_model parsing Igor Mammedov
2017-02-17 19:05 ` [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model Peter Maydell
2017-02-20 18:55 ` Igor Mammedov
2017-02-20 19:11 ` Peter Maydell
2017-02-21 12:44 ` Igor Mammedov [this message]
2017-02-21 12:55 ` Peter Maydell
2017-02-21 13:56 ` Markus Armbruster
2017-02-21 13:57 ` Peter Maydell
2017-02-21 15:48 ` Markus Armbruster
2017-02-21 18:21 ` Eduardo Habkost
2017-02-21 16:18 ` Paolo Bonzini
2017-02-21 17:59 ` Peter Maydell
2017-02-21 18:41 ` Eduardo Habkost
2017-02-21 18:28 ` Eduardo Habkost
2017-02-21 19:32 ` Peter Maydell
2017-02-22 13:30 ` Igor Mammedov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170221134416.5803b3e5@nial.brq.redhat.com \
--to=imammedo@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=ehabkost@redhat.com \
--cc=marcel@redhat.com \
--cc=mst@redhat.com \
--cc=patches@linaro.org \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=stefanha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).