From: Joerg Roedel <joerg.roedel@amd.com>
To: Alexander Graf <agraf@suse.de>
Cc: Avi Kivity <avi@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH 2/2] QEMU-KVM: Ask kernel about supported svm features
Date: Thu, 4 Mar 2010 12:40:43 +0100 [thread overview]
Message-ID: <20100304114043.GM31544@amd.com> (raw)
In-Reply-To: <4EFDD92C-2F6D-4ADD-889E-DD5289A9BC98@suse.de>
On Wed, Mar 03, 2010 at 11:58:49PM +0100, Alexander Graf wrote:
>
> Am 03.03.2010 um 20:15 schrieb Joerg Roedel <joerg.roedel@amd.com>:
>
> >This patch adds code to ask the kernel about the svm
> >features it supports for its guests and propagates them to
> >the guest. The new capability is necessary because the old
> >behavior of the kernel was to just return the host svm
> >features but every svm-feature needs emulation in the nested
> >svm kernel code. The new capability indicates that the
> >kernel is aware of that when returning svm cpuid
> >information.
>
> Do we really need that complexity?
Yes :-)
> By default the kernel masks out unsupported cpuid features anyway. So
> if we don't have npt guest support (enabled), the kernel module should
> just mask it out.
The kernel does not mask out unsupported features. I also don't think
this would be a good idea because userspace won't be aware of that
change.
Fact it, we need a way to report the npt-emulation feature to userspace
because old kvm versions don't support it. So we can't pass the npt bit
unconditionally. The get_supported_cpuid ioctl is the way of choice
here.
But the current way get_supported_cpuid works for function 0x8000000a is
broken because it reports the host features. This was the reason to
introduce the new capability.
> IOW, always passing npt should work. No capability should make it
> get masked out.
No, as stated above always passing npt-bit into the kernel and letting
it mask out there isn't a good way to go (not only because this will
break if you use new qem-kvm on old kernel-space).
Joerg
next prev parent reply other threads:[~2010-03-04 11:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-03 19:15 [PATCH 0/2][RFC] Nested Paging support for Nested SVM (userspace part) Joerg Roedel
2010-03-03 19:15 ` [PATCH 1/2] QEMU-KVM: Fix ext3_feature propagation Joerg Roedel
2010-03-03 19:15 ` [PATCH 2/2] QEMU-KVM: Ask kernel about supported svm features Joerg Roedel
2010-03-03 22:58 ` Alexander Graf
2010-03-04 11:40 ` Joerg Roedel [this message]
2010-03-04 11:44 ` Alexander Graf
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=20100304114043.GM31544@amd.com \
--to=joerg.roedel@amd.com \
--cc=agraf@suse.de \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
/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.