From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suravee Suthikulpanit Subject: Re: [PATCH 1/1 V5] x86/AMD: Fix nested svm crash due to assertion in __virt_to_maddr Date: Mon, 12 Aug 2013 09:04:36 -0500 Message-ID: <5208EB74.6050507@amd.com> References: <1375691514-3426-1-git-send-email-suravee.suthikulpanit@amd.com> <520264F102000078000E9EFA@nat28.tlf.novell.com> <5202C7A5.4070304@amd.com> <52035B0C02000078000EA1B5@nat28.tlf.novell.com> <5208A396.5090106@amazon.de> <5208C06F02000078000EB0C9@nat28.tlf.novell.com> <5208C376.5010905@amazon.de> <5208FCB402000078000EB31A@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5973172195296904539==" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1V8sjn-0004QZ-EW for xen-devel@lists.xenproject.org; Mon, 12 Aug 2013 14:04:47 +0000 In-Reply-To: <5208FCB402000078000EB31A@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel , Christoph Egger , tim@xen.org List-Id: xen-devel@lists.xenproject.org --===============5973172195296904539== Content-Type: multipart/alternative; boundary="------------070508030008020507060506" --------------070508030008020507060506 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 8/12/2013 8:18 AM, Jan Beulich wrote: >>>> On 12.08.13 at 13:13, "Egger, Christoph" wrote: >> On 12.08.13 11:01, Jan Beulich wrote: >>>>>> On 12.08.13 at 10:57, "Egger, Christoph" wrote: >>>> On 08.08.13 08:47, Jan Beulich wrote: >>>>> In any case - explaining how nestedhvm_enabled() could end up >>>>> returning a value different from hvm_svm_enabled() would help >>>>> my understanding. >>>> nestedhvm_enabled() returns true when 'nestedhvm=1' in the >>>> guest config file. >>>> >>>> hvm_svm_enabled() returns true when the hvm guest enabled SVM >>>> in EFER. >>> And the guest should certainly be disallowed to enable SVM in >>> EFER when nestedhvm was not 1 in the config file. >> That's correct. The guest should also never see SVM available via >> cpuid. >> Analogous same regarding VMX on Intel. > So Suravee, bottom line from this is: Replace the prior checks > instead of adding the new ones. > > Jan > > Ok... I will replace the hvm_svm_enabled() to check the EFER.SVME bit instead. I sent out the V6 on Friday which I haveseparated the patch into two. Would you mind taking one last quick look. Thank you, Suravee --------------070508030008020507060506 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 8/12/2013 8:18 AM, Jan Beulich wrote:
On 12.08.13 at 13:13, "Egger, Christoph" <chegger@amazon.de> wrote:

On 12.08.13 11:01, Jan Beulich wrote:

On 12.08.13 at 10:57, "Egger, Christoph" <chegger@amazon.de> wrote:

On 08.08.13 08:47, Jan Beulich wrote:

In any case - explaining how nestedhvm_enabled() could end up
returning a value different from hvm_svm_enabled() would help
my understanding.

nestedhvm_enabled() returns true when 'nestedhvm=1' in the
guest config file.

hvm_svm_enabled() returns true when the hvm guest enabled SVM
in EFER.

And the guest should certainly be disallowed to enable SVM in
EFER when nestedhvm was not 1 in the config file.

That's correct. The guest should also never see SVM available via
cpuid.
Analogous same regarding VMX on Intel.

So Suravee, bottom line from this is: Replace the prior checks
instead of adding the new ones.

Jan
Ok... I will replace the hvm_svm_enabled() to check the EFER.SVME bit instead. 
I sent out the V6 on Friday which I have separated the patch into two. 
Would you mind taking one last quick look.

Thank you,

Suravee
 --------------070508030008020507060506-- --===============5973172195296904539== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5973172195296904539==--