From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bandan Das Subject: Re: [PATCH] Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS Date: Wed, 07 Oct 2015 10:58:07 -0400 Message-ID: References: <560D1C6E.2060803@suse.com> <560D278F.10801@redhat.com> <20151006102838.GD20886@8bytes.org> <20151007110335.GA28811@8bytes.org> Mime-Version: 1.0 Content-Type: text/plain Cc: Paolo Bonzini , kvm@vger.kernel.org, Dirk =?utf-8?Q?M=C3=BCller?= To: Joerg Roedel Return-path: Received: from mx1.redhat.com ([209.132.183.28]:49862 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753955AbbJGO6J (ORCPT ); Wed, 7 Oct 2015 10:58:09 -0400 In-Reply-To: <20151007110335.GA28811@8bytes.org> (Joerg Roedel's message of "Wed, 7 Oct 2015 13:03:36 +0200") Sender: kvm-owner@vger.kernel.org List-ID: Joerg Roedel writes: > On Tue, Oct 06, 2015 at 01:59:27PM -0400, Bandan Das wrote: >> Joerg Roedel writes: >> > >> > So svm->vmcb->control.next_rip is only written by hardware or in >> > svm_check_intercept(). Both cases write only to this field, if the >> > hardware supports X86_FEATURE_NRIPS. The write in nested_svm_vmexit only >> >> Not until commit f104765b4f81fd74d69e0eb161e89096deade2db. So, an older L1 >> kernel will trigger it. > > But we don't care if L1 writes something into its own next_rip, as we > never read this value from its VMCB. We only copy the next_rip value we > get from our shadow-vmcb to it on an emulated vmexit. So I still don't > understand what triggers the reported problem or why the WARN_ON is > necessary. Ok, looks like I am making some incorrect "vmx" assumptions here. What happens when we exit from L2 to L0, arent' we looking at the VMCB L1 is using to run L2 ? Wouldn't that trigger the warning if the host processor does not support nrips and the field is set ? > > Joerg