qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Przywara, Andre" <Andre.Przywara@amd.com>,
	KVM list <kvm@vger.kernel.org>,
	john cooper <john.cooper@redhat.com>,
	dlaor@redhat.com, qemu-devel@nongnu.org,
	Chris Wright <chrisw@sous-sol.org>
Subject: Re: [Qemu-devel] [PATCH] Add definitions for current cpu models..
Date: Tue, 26 Jan 2010 06:54:04 -0600	[thread overview]
Message-ID: <4B5EE5EC.4020006@codemonkey.ws> (raw)
In-Reply-To: <4B5EA749.1000502@redhat.com>

On 01/26/2010 02:26 AM, Gerd Hoffmann wrote:
> On 01/25/10 23:35, Dor Laor wrote:
>> On 01/25/2010 04:21 PM, Anthony Liguori wrote:
>>> 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
> >
>> If we get the models right, users and mgmt stacks won't need to define
>> them. It seems like almost impossible task for us, mgmt stack/users
>> won't do a better job, the opposite I guess. The configs are great, I
>> have no argument against them, my case is that if we can pin down some
>> definitions, its better live in the code, like the above models.
>> It might even help to get the same cpus across the various vendors,
>> otherwise we might end up with IBM's core2duo, RH's core2duo, Suse's,..
>
> I agree.  When looking at this thread and config file idea it feels a 
> bit like "we have a hard time to agree on some sensible default cpu 
> types, so lets make this configurable so we don't have to".  Which is 
> a bad thing IMHO.

There's no sensible default.  If a user only has Nehalem-EX class 
processors and Westmeres, why would they want to limit themselves to 
just Nehalem?  For an organization that already uses and understand the 
VMware grouping, is it wrong for them to want to just use VMware-style 
grouping?

This feature is purely data driven.  There is no code involved.  Any 
time a feature is purely data driven and there isn't a clear right and 
wrong solution, a configuration file is a natural solution IMHO.

I think the only real question is whether it belongs in the default 
config or a dedicated configuration file but honestly that's just a 
statement of convention.

Regards,

Anthony Liguori

> cheers,
>   Gerd

  reply	other threads:[~2010-01-26 12:54 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-18 16:45 [Qemu-devel] [PATCH] Add definitions for current cpu models john cooper
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:20       ` Chris Wright
2010-01-19 22:25     ` Anthony Liguori
2010-01-20  0:15       ` Chris Wright
2010-01-20 14:21         ` Anthony Liguori
2010-01-20 14:27           ` Gleb Natapov
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:53           ` Anthony Liguori
2010-01-21  0:25           ` Chris Wright
2010-01-21  1:18             ` john cooper
2010-01-21 14:39               ` Andre Przywara
2010-01-21 17:06                 ` Blue Swirl
2010-01-21 15:05               ` Anthony Liguori
2010-01-21 16:43                 ` john cooper
2010-01-21 18:59                   ` Anthony Liguori
2010-01-25  9:08                 ` Dor Laor
2010-01-25 11:27                   ` Jamie Lokier
2010-01-25 14:21                   ` Anthony Liguori
2010-01-25 22:35                     ` Dor Laor
2010-01-26  8:26                       ` Gerd Hoffmann
2010-01-26 12:54                         ` Anthony Liguori [this message]
2010-01-28  8:19                   ` Arnd Bergmann
2010-01-28  8:43                     ` Alexander Graf
2010-01-28 10:09                       ` Arnd Bergmann
2010-01-28 14:10                       ` Anthony Liguori
2010-01-19 22:11   ` Jamie Lokier
2010-01-20 20:09     ` john cooper
2010-01-21 17:50       ` Jamie Lokier
2010-01-21 18:13       ` Jamie Lokier
2010-01-21 18:36         ` john cooper
2010-01-19 22:15 ` Jamie Lokier
2010-01-20 20:11   ` john cooper
2010-01-21 17:55     ` Jamie Lokier
2010-01-21 18:34       ` john cooper
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

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=4B5EE5EC.4020006@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=Andre.Przywara@amd.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 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).