Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp979843ybl; Fri, 10 Jan 2020 09:56:38 -0800 (PST) X-Google-Smtp-Source: APXvYqyM/pgSDo4ojLyohmfNwiMroCf9W9ITWtJcYwv8ZLfC1HBsIuTdN64uGnhEjqTVGFTzNRlE X-Received: by 2002:a9d:6857:: with SMTP id c23mr3390829oto.351.1578678997964; Fri, 10 Jan 2020 09:56:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578678997; cv=none; d=google.com; s=arc-20160816; b=SEUoqF3ZB2LAyRpOWi0Auh1AU6XD4OoS7vWUjIORCttCFPjKfDGaTHSlM3GGMQLTBW LDBOnr0H2+R09IfD/HJ1Alrbycijy6MagXLSejjRBR8PaAjWrupBKxhYvkoy0AsfubGa TQ6Rj3HeckGr0AU31uFYkn2H3ta7khqKVaM9tk4B0DxIM9Be8yvuGaV0tgQa/wDLqOIU GHeD6TS39jUAtxG6sxY1pIFKBzQOdFBnqmfyF2aP6f3xfZeX0kQbaOBTV1EY+mB+Zyxb l5O7f0Oy6qGoruuhAbZ26pTEA7Fa9zBv3VV3MItO2EuVuTZEBPnoYbsa+lrS5oE25UMq xHvQ== 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; bh=qmQFxD8kIlP6ID3Ze0DbRe2vNOkIArv1/sbLIIEU6l0=; b=i1QYqUYu+4qHK7UsuLxGdmmQfTGDdoaY9CKaCw21hyxsRfIeR5+BoOwEQ1TEGIy4Mq fUjamfuXRBlunPwDH525B6Yp1UGGsy00X/74FgGAs0FydBfJEGZe1vKJP4qTvviEM9YV lLdUAhsxfmzlRjdxu2U360cvyjAXEfMs7CD3+UwfduwvEFr1SwQQT523K477cPYJx+dF gkqTIUOziWZxdt36e9+MFJ6N3if3ncmasbiRJ32zQ1dsSJ/4xurH9WE/BdNRCpF3FSgA dM6GHp9UWqCxn45GLu8i/57vDctpoeXNpO4NVdC3sAOfZTfbHSPwZu45fzcMgFyzWsrD pvew== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id d20si1849327oti.311.2020.01.10.09.56.27; Fri, 10 Jan 2020 09:56:37 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1728815AbgAJRzi (ORCPT + 99 others); Fri, 10 Jan 2020 12:55:38 -0500 Received: from mga01.intel.com ([192.55.52.88]:14202 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728616AbgAJRzi (ORCPT ); Fri, 10 Jan 2020 12:55:38 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jan 2020 09:55:38 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,417,1571727600"; d="scan'208";a="238279735" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.202]) by orsmga002.jf.intel.com with ESMTP; 10 Jan 2020 09:55:37 -0800 Date: Fri, 10 Jan 2020 09:55:37 -0800 From: Sean Christopherson To: Yang Weijiang Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, pbonzini@redhat.com, jmattson@google.com, yu.c.zhang@linux.intel.com, alazar@bitdefender.com, edwin.zhai@intel.com Subject: Re: [RESEND PATCH v10 06/10] vmx: spp: Set up SPP paging table at vmentry/vmexit Message-ID: <20200110175537.GF21485@linux.intel.com> References: <20200102061319.10077-1-weijiang.yang@intel.com> <20200102061319.10077-7-weijiang.yang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200102061319.10077-7-weijiang.yang@intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 02, 2020 at 02:13:15PM +0800, Yang Weijiang wrote: > If write to subpage is not allowed, EPT violation generates > and it's handled in fast_page_fault(). > > In current implementation, SPPT setup is only handled in handle_spp() > vmexit handler, it's triggered when SPP bit is set in EPT leaf > entry while SPPT entries are not ready. > > A SPP specific bit(11) is added to exit_qualification and a new > exit reason(66) is introduced for SPP. ... > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > index 6f92b40d798c..c41791ebee65 100644 > --- a/arch/x86/kvm/mmu/mmu.c > +++ b/arch/x86/kvm/mmu/mmu.c > @@ -6372,6 +6427,8 @@ unsigned long kvm_mmu_calculate_default_mmu_pages(struct kvm *kvm) > return nr_mmu_pages; > } > > +#include "spp.c" > + Unless there is a *very* good reason for these shenanigans, spp.c needs to built via the Makefile like any other source. If this is justified for whatever reason, then that justification needs to be very clearly stated in the changelog. In general, the code organization of this entire series likely needs to be overhauled. There are gobs exports which are either completely unnecessary or completely backswards. E.g. exporting VMX-only functions from spp.c, which presumably are only callbed by VMX. EXPORT_SYMBOL_GPL(vmx_spp_flush_sppt); EXPORT_SYMBOL_GPL(vmx_spp_init); Exporting ioctl helpers from the same file, which are presumably called only from x86.c. EXPORT_SYMBOL_GPL(kvm_vm_ioctl_get_subpages); EXPORT_SYMBOL_GPL(kvm_vm_ioctl_set_subpages);