qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: "Roedel, Joerg" <Joerg.Roedel@amd.com>
Cc: Andre Przywara <andre.przywara@amd.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [Qemu-devel] semantics of "-cpu host" and "check"/"enforce"
Date: Sun, 12 Jun 2011 17:36:41 +0300	[thread overview]
Message-ID: <4DF4CEF9.6070906@redhat.com> (raw)
In-Reply-To: <20110611104019.GD29908@amd.com>

On 06/11/2011 01:40 PM, Roedel, Joerg wrote:
> On Fri, Jun 10, 2011 at 05:36:37PM -0400, Eduardo Habkost wrote:
>
> >  We have 3 sets of cpu features that may or may not be included in
> >  '-cpu host':
> >
> >  A) Features that are supported by the host and that KVM can already
> >     emulate, or don't need KVM support to be used;
> >  B) Features that may be not supported by the host but can be emulated by
> >     KVM (e.g. the SVM features, or x2apic);
> >  C) Features that are supported by the host but KVM can't emulate.
> >     Divided in:
> >     C1) features we can't emulate and we know about it (e.g. dtes64)[1]
> >     C2) features we possibly can't emulate but we don't even know about it
> >         (e.g. features added to recent CPUs).
> >
> >  It seems obvious that all the features in group A must always be
> >  included in '-cpu host', but what about features in the B or C groups?
> >
> >
> >  About group B: it looks like we are not being consistent. For example,
> >  svm_features has every bit enabled when using '-cpu host' even if the
> >  host doesn't support them; in other cases (e.g. x2apic), it is not
> >  enabled by '-cpu host' unless the host already supports it.
>
> SVM is a special feature. We can't just forward the host-cpuid to the
> guest because every SVM feature we provide to the guest needs emulation
> in the kernel module. The kernel-module will tell qemu-kvm about its
> feature set via the GET_SUPPORTED_CPUID ioctl.

SVM isn't special in this regard.  It's potentially true for any 
feature, and actually true for some of them.

> So the idea behint -cpu
> host and SVM features is that qemu-kvm enables all of them and masks out
> everything that is not supported by the kernel module.

Right (but by whitelisting known features, not blacklisting).

> Note that the kernel might even emulate features that are not supported
> on the host, like the vmcb-clean-bits, so we really need to ask the
> kernel what is supported for the guest.

x2apic is another example.

-- 
error compiling committee.c: too many arguments to function

  reply	other threads:[~2011-06-12 14:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-10 21:36 [Qemu-devel] semantics of "-cpu host" and "check"/"enforce" Eduardo Habkost
2011-06-11 10:40 ` Roedel, Joerg
2011-06-12 14:36   ` Avi Kivity [this message]
2011-06-12 14:48 ` Avi Kivity

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=4DF4CEF9.6070906@redhat.com \
    --to=avi@redhat.com \
    --cc=Joerg.Roedel@amd.com \
    --cc=andre.przywara@amd.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).