qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>,
	qemu-devel@nongnu.org, Anthony Liguori <anthony@codemonkey.ws>,
	Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [Qemu-devel] [PATCH 0/3] Move CPU model definitions to C
Date: Wed, 01 Aug 2012 22:04:50 +0200	[thread overview]
Message-ID: <50198BE2.4050005@suse.de> (raw)
In-Reply-To: <1343846728-8611-1-git-send-email-ehabkost@redhat.com>

Am 01.08.2012 20:45, schrieb Eduardo Habkost:
> This makes the change we discussed on the latest KVM conf call[1], moving the
> existing cpudefs from cpus-x86_64.conf to the C code.
> 
> The config file data was converted to C using a script, available at:
> https://gist.github.com/3229602
> 
> Except by the extra square brackets around the CPU model names (indicating they
> are built-in models), the output of "-cpu ?dump" is exactly the same before and
> after applying this series.
> 
> [1] http://article.gmane.org/gmane.comp.emulators.kvm.devel/95328
> 
> Eduardo Habkost (3):
>   i386: add missing CPUID_* constants
>   move CPU models from cpus-x86_64.conf to C
>   eliminate cpus-x86_64.conf file

If we do this, we will need to refactor the C code again for CPU
subclasses. Can't we (you) do that in one go then? :-)

I thought there was a broad consensus not to go my declarative
X86CPUInfo way but to initialize CPUs imperatively as done for ARM.
That would mean transforming your

+    {
+        .family = 6,
+        .model = 2,
...

into an initfn doing

-    {
+static void conroe_initfn(Object *obj)
+{
+    X86CPU *cpu = X86_CPU(obj);
+    CPUX86State *env = &cpu->env;
+
-        .family = 6,
+    env->family = 6;
-        .model = 2,
+    env->model = 2;
...

or so (not all being as nicely aligned).

Unfortunately the move of the CPU definitions from config file to C does
not eliminate the issue that users can still specify CPU models in their
own config files or from the command line, right? Doesn't that mean that
either we need to keep all CPU definitions declarative as done here and
live with any field duplication between X86CPUInfo and X86CPUClass, or
have a special intermediate subclass UserX86CPUClass with such fields
for user-specified -cpudef models?
Assuming, dropping -cpudef for 1.2 is still not an option.

Regards,
Andreas

> 
>  Makefile                           |   1 -
>  arch_init.c                        |   1 -
>  sysconfigs/target/cpus-x86_64.conf | 128 ----------------------
>  target-i386/cpu.c                  | 219 +++++++++++++++++++++++++++++++++++++
>  target-i386/cpu.h                  |  22 ++++
>  5 files changed, 241 insertions(+), 130 deletions(-)
>  delete mode 100644 sysconfigs/target/cpus-x86_64.conf
> 


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

  parent reply	other threads:[~2012-08-01 20:04 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-01 18:45 [Qemu-devel] [PATCH 0/3] Move CPU model definitions to C Eduardo Habkost
2012-08-01 18:45 ` [Qemu-devel] [PATCH 1/3] i386: add missing CPUID_* constants Eduardo Habkost
2012-08-01 18:45 ` [Qemu-devel] [PATCH 2/3] move CPU models from cpus-x86_64.conf to C Eduardo Habkost
2012-08-01 18:45 ` [Qemu-devel] [PATCH 3/3] eliminate cpus-x86_64.conf file Eduardo Habkost
2012-08-01 19:37   ` Lluís Vilanova
2012-08-01 19:53     ` Eduardo Habkost
2012-08-02 10:11       ` Lluís Vilanova
2012-08-01 18:53 ` [Qemu-devel] [PATCH 0/3] Move CPU model definitions to C Anthony Liguori
2012-08-13 18:36   ` Eduardo Habkost
2012-08-01 20:04 ` Andreas Färber [this message]
2012-08-01 20:27   ` Eduardo Habkost
2012-08-01 20:41     ` Anthony Liguori
2012-08-02 12:01       ` Eduardo Habkost
2012-08-01 21:53     ` Andreas Färber
2012-08-02 11:44       ` Igor Mammedov
2012-08-02 12:15       ` Eduardo Habkost

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=50198BE2.4050005@suse.de \
    --to=afaerber@suse.de \
    --cc=anthony@codemonkey.ws \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /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).