Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp1661208pxa; Thu, 20 Aug 2020 17:45:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxD5rAU5K4D0VauVU6qUvFl1TSPLIR05QO3wZRzzxRRO0K3mdbjbVQvzQyfgsD/c7qQcPpJ X-Received: by 2002:aa7:db59:: with SMTP id n25mr480357edt.276.1597970704623; Thu, 20 Aug 2020 17:45:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597970704; cv=none; d=google.com; s=arc-20160816; b=SkF175udXZRs1/PkAsECP2pzFhpBc7zGKcXYvih7n1d/myw7jSWFdZZ71YmezgDhcw Hdp3NYuOe2Md0W6jjTvbmay4j/3YdyFUoFwn9xCRiVcfMN7H04kQOnxfyYOgC9ldXkHs 9xrdHl7L0X5axwMu6JCeoXTlLzbi3oH7hCRiS1vv8VQ2iM6V49IU/b+5En6DlWDygW4i 57svwgyO5xuqZ11x526NC1Nln6IKih8zZFFQgd5YiCCTVWDuUeXsgskE58vqxGCVkGV+ Uf7I6KOmiOiDyScCUWmVqmCqrMHH35XM/Hs2I76KQ9AyE4eDCZhkJPk96+haTMiBkJLE m4cg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:ironport-sdr:ironport-sdr; bh=uz58NQ2b1aqTL9dQX3gaRuKlbtheJYSTHgP/LmzyhK0=; b=AXahaxIRjj1F+efbaDu/MUCxMRohlCd8grtOWqr2o8H1Mbujy9ozXdg1Pjdg4QW5VS R5+0XzRMHaE/Vo5Qs7aprmuqngp4eWrwKEb9LNogpOpbvidy3RM2/5EO6H69Z68pJUdP ADfVGXtyQf8bj0eIAUlfdsVd5jouoH9UGZNaoiE6Fqt8irEjmUy9yQ+f0TlW9qghhOqX aETegjfJbLjPFlg3KmSQZ3xqIbWrsnwZowsfE9DuC2sTUsbWtkZFL+9tfGFk0DJ0lHDN xfwsPt0aqTioOA4mUov617BCfscstQg6TVCqqfNB88wy7ID9MJ1sxXSpqu1ZfiPjLTOG YQWA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j22si75901ejx.663.2020.08.20.17.44.42; Thu, 20 Aug 2020 17:45:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727086AbgHUAny (ORCPT + 99 others); Thu, 20 Aug 2020 20:43:54 -0400 Received: from mga01.intel.com ([192.55.52.88]:22591 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726347AbgHUAnw (ORCPT ); Thu, 20 Aug 2020 20:43:52 -0400 IronPort-SDR: zZc69eXsPDu1+auV9GcrajuqBRqeA8da9q4si91JxTNBTK9Kr57lsw4TCHkFSywF+Pscjyngzp gDHbobK/Fpuw== X-IronPort-AV: E=McAfee;i="6000,8403,9719"; a="173475545" X-IronPort-AV: E=Sophos;i="5.76,335,1592895600"; d="scan'208";a="173475545" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Aug 2020 17:43:52 -0700 IronPort-SDR: CV+aD4RVikqpucere4ciRE8C/vejzgapN3ODrrIRnN9LOYhBkdBPuOorNfcXFydm5tLFtevSSG e7B+Vcfib0xg== X-IronPort-AV: E=Sophos;i="5.76,335,1592895600"; d="scan'208";a="498345362" Received: from sjchrist-ice.jf.intel.com (HELO sjchrist-ice) ([10.54.31.34]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Aug 2020 17:43:50 -0700 Date: Thu, 20 Aug 2020 17:43:50 -0700 From: Sean Christopherson To: Jim Mattson Cc: Maxim Levitsky , kvm list , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Ingo Molnar , Thomas Gleixner , "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "H. Peter Anvin" , Joerg Roedel , Wanpeng Li , Borislav Petkov , Vitaly Kuznetsov , Paolo Bonzini Subject: Re: [PATCH v2 4/7] KVM: x86: allow kvm_x86_ops.set_efer to return a value Message-ID: <20200821004350.GB13886@sjchrist-ice> References: <20200820133339.372823-1-mlevitsk@redhat.com> <20200820133339.372823-5-mlevitsk@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 20, 2020 at 02:43:56PM -0700, Jim Mattson wrote: > On Thu, Aug 20, 2020 at 6:34 AM Maxim Levitsky wrote: > > > > This will be used later to return an error when setting this msr fails. > > > > For VMX, it already has an error condition when EFER is > > not in the shared MSR list, so return an error in this case. > > > > Signed-off-by: Maxim Levitsky > > --- > > > --- a/arch/x86/kvm/x86.c > > +++ b/arch/x86/kvm/x86.c > > @@ -1471,7 +1471,8 @@ static int set_efer(struct kvm_vcpu *vcpu, struct msr_data *msr_info) > > efer &= ~EFER_LMA; > > efer |= vcpu->arch.efer & EFER_LMA; > > > > - kvm_x86_ops.set_efer(vcpu, efer); > > + if (kvm_x86_ops.set_efer(vcpu, efer)) > > + return 1; > > This seems like a userspace ABI change to me. Previously, it looks > like userspace could always use KVM_SET_MSRS to set MSR_EFER to 0 or > EFER_SCE, and it would always succeed. Now, it looks like it will fail > on CPUs that don't support EFER in hardware. (Perhaps it should fail, > but it didn't before, AFAICT.) KVM emulates SYSCALL, presumably that also works when EFER doesn't exist in hardware. The above also adds weirdness to nested VMX as vmx_set_efer() simply can't fail.