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
next prev parent 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).