All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: john cooper <john.cooper@redhat.com>
Cc: KVM list <kvm@vger.kernel.org>,
	qemu-devel@nongnu.org, "Przywara, Andre" <Andre.Przywara@amd.com>
Subject: Re: [Qemu-devel] [PATCH] Add definitions for current cpu models..
Date: Thu, 21 Jan 2010 17:55:30 +0000	[thread overview]
Message-ID: <20100121175530.GB28467@shareable.org> (raw)
In-Reply-To: <4B57638A.1060103@redhat.com>

john cooper wrote:
> > I foresee wanting to iterate over the models and pick the latest one
> > which a host supports - on the grounds that you have done the hard
> > work of ensuring it is a reasonably good performer, while "probably"
> > working on another host of similar capability when a new host is made
> > available.
> 
> That's a fairly close use case to that of safe migration
> which was one of the primary motivations to identify
> the models being discussed.  Although presentation and
> administration of such was considered the domain of management
> tools.

My hypothetical script which iterates over models in that way is a
"management tool", and would use qemu to help do its job.

Do you mean that more powerful management tools to support safe
migration will maintain _their own_ processor model tables, and
perform their calculations using their own tables instead of querying
qemu, and therefore not have any need of qemu's built in table?

If so, I favour more strongly Anthony's suggestion that the processor
model table lives in a config file (eventually), as that file could be
shared between management tools and qemu itself without duplication.

-- Jamie

WARNING: multiple messages have this Message-ID (diff)
From: Jamie Lokier <jamie@shareable.org>
To: john cooper <john.cooper@redhat.com>
Cc: "Przywara, Andre" <Andre.Przywara@amd.com>,
	qemu-devel@nongnu.org, KVM list <kvm@vger.kernel.org>
Subject: Re: [Qemu-devel] [PATCH] Add definitions for current cpu models..
Date: Thu, 21 Jan 2010 17:55:30 +0000	[thread overview]
Message-ID: <20100121175530.GB28467@shareable.org> (raw)
In-Reply-To: <4B57638A.1060103@redhat.com>

john cooper wrote:
> > I foresee wanting to iterate over the models and pick the latest one
> > which a host supports - on the grounds that you have done the hard
> > work of ensuring it is a reasonably good performer, while "probably"
> > working on another host of similar capability when a new host is made
> > available.
> 
> That's a fairly close use case to that of safe migration
> which was one of the primary motivations to identify
> the models being discussed.  Although presentation and
> administration of such was considered the domain of management
> tools.

My hypothetical script which iterates over models in that way is a
"management tool", and would use qemu to help do its job.

Do you mean that more powerful management tools to support safe
migration will maintain _their own_ processor model tables, and
perform their calculations using their own tables instead of querying
qemu, and therefore not have any need of qemu's built in table?

If so, I favour more strongly Anthony's suggestion that the processor
model table lives in a config file (eventually), as that file could be
shared between management tools and qemu itself without duplication.

-- Jamie

  reply	other threads:[~2010-01-21 17:55 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
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 [this message]
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=20100121175530.GB28467@shareable.org \
    --to=jamie@shareable.org \
    --cc=Andre.Przywara@amd.com \
    --cc=john.cooper@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.