All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: dlaor@redhat.com
Cc: john cooper <john.cooper@redhat.com>,
	Chris Wright <chrisw@sous-sol.org>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	"Przywara, Andre" <Andre.Przywara@amd.com>,
	qemu-devel@nongnu.org, KVM list <kvm@vger.kernel.org>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] Add definitions for current cpu models..
Date: Mon, 25 Jan 2010 08:21:18 -0600	[thread overview]
Message-ID: <4B5DA8DE.3040600@codemonkey.ws> (raw)
In-Reply-To: <4B5D5F84.4040507@redhat.com>

On 01/25/2010 03:08 AM, Dor Laor wrote:
>> qemu-config.[ch], taking a new command line that parses the argument via
>> QemuOpts, then passing the parsed options to a target-specific function
>> that then builds the table of supported cpus.
> It should just be a matter of adding qemu_cpudefs_opts to
>
> Isn't the outcome of John's patches and these configs will be exactly 
> the same? Since these cpu models won't ever change, there is no reason 
> why not to hard code them. Adding configs or command lines is a good 
> idea but it is more friendlier to have basic support to the common cpus.
> This is why qemu today offers: -cpu ?
> x86           qemu64
> x86           phenom
> x86         core2duo
> x86            kvm64
> x86           qemu32
> x86          coreduo
> x86              486
> x86          pentium
> x86         pentium2
> x86         pentium3
> x86           athlon
> x86             n270
>
> So bottom line, my point is to have John's base + your configs. We 
> need to keep also the check verb and the migration support for sending 
> those.
>
> btw: IMO we should deal with this complexity ourselves and save 99.9% 
> of the users the need to define such models, don't ask this from a 
> java programmer, he is running on a JVM :-)

I'm suggesting John's base should be implemented as a default config 
that gets installed by default in QEMU.  The point is that a smart user 
(or a downstream) can modify this to suite their needs more appropriately.

Another way to look at this is that implementing a somewhat arbitrary 
policy within QEMU's .c files is something we should try to avoid.  
Implementing arbitrary policy in our default config file is a fine thing 
to do.  Default configs are suggested configurations that are modifiable 
by a user.  Something baked into QEMU is something that ought to work 
for everyone in all circumstances.

Regards,

Anthony Liguori

WARNING: multiple messages have this Message-ID (diff)
From: Anthony Liguori <anthony@codemonkey.ws>
To: dlaor@redhat.com
Cc: "Przywara, Andre" <Andre.Przywara@amd.com>,
	KVM list <kvm@vger.kernel.org>,
	john cooper <john.cooper@redhat.com>,
	qemu-devel@nongnu.org, Chris Wright <chrisw@sous-sol.org>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] Add definitions for current cpu models..
Date: Mon, 25 Jan 2010 08:21:18 -0600	[thread overview]
Message-ID: <4B5DA8DE.3040600@codemonkey.ws> (raw)
In-Reply-To: <4B5D5F84.4040507@redhat.com>

On 01/25/2010 03:08 AM, Dor Laor wrote:
>> qemu-config.[ch], taking a new command line that parses the argument via
>> QemuOpts, then passing the parsed options to a target-specific function
>> that then builds the table of supported cpus.
> It should just be a matter of adding qemu_cpudefs_opts to
>
> Isn't the outcome of John's patches and these configs will be exactly 
> the same? Since these cpu models won't ever change, there is no reason 
> why not to hard code them. Adding configs or command lines is a good 
> idea but it is more friendlier to have basic support to the common cpus.
> This is why qemu today offers: -cpu ?
> x86           qemu64
> x86           phenom
> x86         core2duo
> x86            kvm64
> x86           qemu32
> x86          coreduo
> x86              486
> x86          pentium
> x86         pentium2
> x86         pentium3
> x86           athlon
> x86             n270
>
> So bottom line, my point is to have John's base + your configs. We 
> need to keep also the check verb and the migration support for sending 
> those.
>
> btw: IMO we should deal with this complexity ourselves and save 99.9% 
> of the users the need to define such models, don't ask this from a 
> java programmer, he is running on a JVM :-)

I'm suggesting John's base should be implemented as a default config 
that gets installed by default in QEMU.  The point is that a smart user 
(or a downstream) can modify this to suite their needs more appropriately.

Another way to look at this is that implementing a somewhat arbitrary 
policy within QEMU's .c files is something we should try to avoid.  
Implementing arbitrary policy in our default config file is a fine thing 
to do.  Default configs are suggested configurations that are modifiable 
by a user.  Something baked into QEMU is something that ought to work 
for everyone in all circumstances.

Regards,

Anthony Liguori

  parent reply	other threads:[~2010-01-25 14:27 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-18 16:45 [PATCH] Add definitions for current cpu models john cooper
2010-01-18 16:45 ` [Qemu-devel] " john cooper
2010-01-19 19:39 ` Anthony Liguori
2010-01-19 19:39   ` Anthony Liguori
2010-01-19 20:03   ` Chris Wright
2010-01-19 22:12     ` Jamie Lokier
2010-01-19 22:12       ` Jamie Lokier
2010-01-19 22:20       ` Chris Wright
2010-01-19 22:20         ` Chris Wright
2010-01-19 22:25     ` Anthony Liguori
2010-01-20  0:15       ` Chris Wright
2010-01-20  0:15         ` Chris Wright
2010-01-20 14:21         ` Anthony Liguori
2010-01-20 14:27           ` Gleb Natapov
2010-01-20 14:27             ` Gleb Natapov
2010-01-20  1:38       ` Jamie Lokier
2010-01-20  1:38         ` Jamie Lokier
2010-01-20 20:09       ` john cooper
2010-01-20 20:26         ` Daniel P. Berrange
2010-01-20 20:26           ` Daniel P. Berrange
2010-01-20 20:53           ` Anthony Liguori
2010-01-20 20:53             ` Anthony Liguori
2010-01-21  0:25           ` Chris Wright
2010-01-21  0:25             ` Chris Wright
2010-01-21  1:18             ` john cooper
2010-01-21  1:18               ` john cooper
2010-01-21 14:39               ` Andre Przywara
2010-01-21 14:39                 ` Andre Przywara
2010-01-21 17:06                 ` Blue Swirl
2010-01-21 15:05               ` Anthony Liguori
2010-01-21 15:05                 ` Anthony Liguori
2010-01-21 16:43                 ` john cooper
2010-01-21 16:43                   ` john cooper
2010-01-21 18:59                   ` Anthony Liguori
2010-01-21 18:59                     ` Anthony Liguori
2010-01-25  9:08                 ` Dor Laor
2010-01-25  9:08                   ` Dor Laor
2010-01-25 11:27                   ` Jamie Lokier
2010-01-25 11:27                     ` Jamie Lokier
2010-01-25 14:21                   ` Anthony Liguori [this message]
2010-01-25 14:21                     ` Anthony Liguori
2010-01-25 22:35                     ` Dor Laor
2010-01-26  8:26                       ` Gerd Hoffmann
2010-01-26  8:26                         ` Gerd Hoffmann
2010-01-26 12:54                         ` Anthony Liguori
2010-01-26 12:54                           ` Anthony Liguori
2010-01-28  8:19                   ` Arnd Bergmann
2010-01-28  8:19                     ` Arnd Bergmann
2010-01-28  8:43                     ` Alexander Graf
2010-01-28  8:43                       ` Alexander Graf
2010-01-28 10:09                       ` Arnd Bergmann
2010-01-28 10:09                         ` Arnd Bergmann
2010-01-28 14:10                       ` Anthony Liguori
2010-01-28 14:10                         ` Anthony Liguori
2010-01-19 22:11   ` Jamie Lokier
2010-01-20 20:09     ` john cooper
2010-01-20 20:09       ` john cooper
2010-01-21 17:50       ` Jamie Lokier
2010-01-21 17:50         ` Jamie Lokier
2010-01-21 18:13       ` Jamie Lokier
2010-01-21 18:13         ` Jamie Lokier
2010-01-21 18:36         ` john cooper
2010-01-21 18:36           ` john cooper
2010-01-19 22:15 ` Jamie Lokier
2010-01-19 22:15   ` Jamie Lokier
2010-01-20 20:11   ` john cooper
2010-01-20 20:11     ` john cooper
2010-01-21 17:55     ` Jamie Lokier
2010-01-21 17:55       ` Jamie Lokier
2010-01-21 18:34       ` john cooper
2010-01-21 18:34         ` john cooper
2010-01-20 23:20 ` Arnd Bergmann
2010-01-20 23:20   ` [Qemu-devel] " Arnd Bergmann
  -- strict thread matches above, loose matches on Subject: below --
2009-12-21  6:46 [Qemu-devel] " john cooper
2009-12-24 13:45 ` Avi Kivity
2009-12-31  3:13 ` Jamie Lokier

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=4B5DA8DE.3040600@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=Andre.Przywara@amd.com \
    --cc=berrange@redhat.com \
    --cc=chrisw@sous-sol.org \
    --cc=dlaor@redhat.com \
    --cc=john.cooper@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=kvm@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.