From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joerg Roedel Subject: Re: [PATCH 2/2] QEMU-KVM: Ask kernel about supported svm features Date: Thu, 4 Mar 2010 12:40:43 +0100 Message-ID: <20100304114043.GM31544@amd.com> References: <1267643742-616-1-git-send-email-joerg.roedel@amd.com> <1267643742-616-3-git-send-email-joerg.roedel@amd.com> <4EFDD92C-2F6D-4ADD-889E-DD5289A9BC98@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Avi Kivity , Marcelo Tosatti , "kvm@vger.kernel.org" To: Alexander Graf Return-path: Received: from va3ehsobe001.messaging.microsoft.com ([216.32.180.11]:4778 "EHLO VA3EHSOBE001.bigfish.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755860Ab0CDLlJ (ORCPT ); Thu, 4 Mar 2010 06:41:09 -0500 Content-Disposition: inline In-Reply-To: <4EFDD92C-2F6D-4ADD-889E-DD5289A9BC98@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Mar 03, 2010 at 11:58:49PM +0100, Alexander Graf wrote: > > Am 03.03.2010 um 20:15 schrieb Joerg Roedel : > > >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