qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: qemu-devel@nongnu.org
Cc: danken@qumranet.com, kvm-devel <kvm-devel@lists.sourceforge.net>
Subject: Re: [Qemu-devel] Re: [kvm-devel] expose host CPU features to guests
Date: Fri, 7 Sep 2007 11:47:38 +0100	[thread overview]
Message-ID: <20070907104738.GA14723@mail.shareable.org> (raw)
In-Reply-To: <1189020371.7206.3.camel@squirrel>

Anthony Liguori wrote:
> I like this idea but I have some suggestions about the general approach.
> I think instead of defining another machine type, it would be better to
> just have a command line option like -cpuid that took a comma separate
> string of features with "all" meaning all features that the host has.

I like the idea of a flag to enable specific features, but I think
"host" would be a better name for the features of the host.

"all" seems more appropriate to enable all the features the emulator
can support, which can include features which the host does not
support itself.

If it's a comma separated list, it would be good to be able to write
something like this example, which selects all the host features but
then overrides it by disabling the psn feature:

   -cpuid host,-psn

Is it intended that these flags will also control the actual features
which Qemu allows or emulates, or only what cpuid reports to the guest?

> I also think it would be nicer to use cpuid() directly instead of
> attempting to parse /proc/cpuinfo.

Occasionally the features in /proc/cpuinfo differ from what the cpuid
instruction reports.  They are CPU bug workarounds (features disabled
intentionally even though cpuid reports them), CPU features which
aren't properly reported (enabled intentionally in cpuinfo), and boot
flag requests (features disabled due to request from the boot command
line).

I'm inclined to think the feature list in /proc/cpuinfo is more
appropriate, for choosing the best set of host features to make
available to guests.  It's unlikely that Qemu itself will duplicate
the logic of known workarounds for specific, obscure, buggy host CPUs.

There is also /dev/cpu/%d/cpuinfo (for %d = 0, 1, etc.) on some Linux
distros, I think.

-- Jamie

  parent reply	other threads:[~2007-09-07 10:47 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-05 17:45 [Qemu-devel] expose host CPU features to guests danken
2007-09-05 19:26 ` [Qemu-devel] Re: [kvm-devel] " Anthony Liguori
2007-09-05 19:34   ` Avi Kivity
2007-09-05 19:44     ` Daniel P. Berrange
2007-09-06  0:30       ` Paul Brook
2007-09-06  8:46         ` Avi Kivity
2007-09-07 10:47   ` Jamie Lokier [this message]
2007-09-09  7:51     ` [kvm-devel] [Qemu-devel] " Avi Kivity
2007-09-09 12:47       ` Jamie Lokier
2007-09-09 12:55         ` Avi Kivity
2007-09-09 13:07           ` Jamie Lokier
2007-09-09 13:14             ` Avi Kivity
2007-09-09 15:25             ` Paul Brook
2007-09-09 15:29               ` Avi Kivity
2007-09-09 15:47                 ` Jamie Lokier
2007-09-09 16:12                 ` Paul Brook
2007-09-09 16:38                   ` Avi Kivity
2007-09-10 16:53                   ` Jamie Lokier
2007-09-10  7:40 ` [Qemu-devel] expose host CPU features to guests: Take 2 Dan Kenigsberg
2007-09-10 11:47   ` Natalia Portillo
2007-09-10 12:01     ` Dan Kenigsberg
2007-09-07 16:18       ` Natalia Portillo
2007-09-11 19:48         ` Luke -Jr
2007-09-10 17:16       ` Jamie Lokier
2007-09-24 17:41   ` [Qemu-devel] expose host CPU features to guests: Take 3 Dan Kenigsberg
2007-09-25  1:28     ` andrzej zaborowski
2007-09-25  8:48       ` [kvm-devel] " Dan Kenigsberg
2007-09-25  9:01         ` Avi Kivity
2007-09-25  9:19           ` J. Mayer
2007-09-25  9:31             ` Avi Kivity
2007-09-25 10:40               ` Avi Kivity
2007-09-25 11:09                 ` J. Mayer
2007-09-25 11:36                   ` Avi Kivity
2007-09-25 12:05                     ` Fabrice Bellard
2007-09-25 13:07                     ` Jocelyn Mayer
2007-09-25 13:12                       ` Avi Kivity
2007-09-25 13:27                       ` Dan Kenigsberg
2007-09-25 15:54                       ` Jamie Lokier
2007-09-25 16:15                         ` Avi Kivity
2007-09-25 12:51               ` Paul Brook
2007-09-25 13:13                 ` Avi Kivity
2007-09-25  9:29       ` Fabrice Bellard
2007-10-07 12:38     ` [Qemu-devel] x86 -cpu option: Take 4 Dan Kenigsberg

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=20070907104738.GA14723@mail.shareable.org \
    --to=jamie@shareable.org \
    --cc=danken@qumranet.com \
    --cc=kvm-devel@lists.sourceforge.net \
    --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).