qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: "qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
	kvm list <kvm@vger.kernel.org>, Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 1/2] KVM: Add new -cpu best
Date: Mon, 16 Jan 2012 20:42:59 +0100	[thread overview]
Message-ID: <C51589EC-0DC4-4DD2-945F-EA31DA7A7B4A@suse.de> (raw)
In-Reply-To: <4F147B78.4090706@codemonkey.ws>


On 16.01.2012, at 20:33, Anthony Liguori wrote:

> On 01/08/2012 05:52 PM, Alexander Graf wrote:
>> During discussions on whether to make -cpu host the default in SLE, I found
>> myself disagreeing to the thought, because it potentially opens a big can
>> of worms for potential bugs. But if I already am so opposed to it for SLE, how
>> can it possibly be reasonable to default to -cpu host in upstream QEMU? And
>> what would a sane default look like?
> 
> 
> What are the arguments against -cpu host?

It's hard to test. New CPUs have new features and we're having a hard time to catch up. With -cpu best we only select from a pool of known-good CPU types. If you want to check that everything works, go to a box that has the maximum available features, go through all -cpu options that users could run into and you're good. With -cpu host you can't really test (unless you own all possible CPUs there are).

We expose CPUID information that doesn't exist that way in the real world.

A small example from today's code.

There are a bunch of CPUID leafs. On Nehalem, one of them is a list of possible C-States to go into. With -cpu host we sync feature bits, CPU name, CPU family and some other bits of information, but not the C-State information. So we end up with a CPU inside the guest that looks and feels like a Nehalem CPU, but doesn't expose any C-State information.

Linux now boots, goes in, checks that it's running on Nehalem, sets the powersave mechanism to the respective model and fills an internal callback table with the C-State information with a loop that ends without any action, since we expose 0 C-State bits. When the guest now calls the idle callback, it dereferences that table, which contains a NULL pointer, oops.

That is just one example from current Linux. Another one would be my development AMD box that when it came out wasn't around in the market yet, so guests would just refuse to boot at all. Since they'd just say the CPUID is unknown.

Overall, I used to be a big fan of -cpu host, but it's a maintainability nightmare. It can be great for testing stuff, so we should definitely keep it around. But after thinking about it again, I don't think it should be the default. The default should be something safe.


Alex

      reply	other threads:[~2012-01-16 19:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-08 23:52 [Qemu-devel] [PATCH 1/2] KVM: Add new -cpu best Alexander Graf
2012-01-08 23:52 ` [Qemu-devel] [PATCH 2/2] KVM: Use -cpu best as default on x86 Alexander Graf
2012-01-16 19:30   ` Ryan Harper
2012-01-16 19:36     ` Alexander Graf
2012-01-16 19:46       ` Ryan Harper
2012-01-16 19:51         ` Alexander Graf
2012-01-16 20:13           ` Ryan Harper
2012-01-16 20:51             ` Alexander Graf
2012-01-16 21:33               ` Ryan Harper
2012-01-09  0:02 ` [Qemu-devel] [PATCH 1/2] KVM: Add new -cpu best Peter Maydell
2012-01-09  0:06   ` Alexander Graf
2012-01-16 19:33 ` Anthony Liguori
2012-01-16 19:42   ` Alexander Graf [this message]

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=C51589EC-0DC4-4DD2-945F-EA31DA7A7B4A@suse.de \
    --to=agraf@suse.de \
    --cc=anthony@codemonkey.ws \
    --cc=avi@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).