From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 31F59C47404 for ; Mon, 14 Oct 2019 06:56:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F249F20673 for ; Mon, 14 Oct 2019 06:56:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F249F20673 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9ACF08E0005; Mon, 14 Oct 2019 02:56:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 95D5D8E0001; Mon, 14 Oct 2019 02:56:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 872CD8E0005; Mon, 14 Oct 2019 02:56:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0120.hostedemail.com [216.40.44.120]) by kanga.kvack.org (Postfix) with ESMTP id 60E2C8E0001 for ; Mon, 14 Oct 2019 02:56:52 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id E5729180AD83A for ; Mon, 14 Oct 2019 06:56:51 +0000 (UTC) X-FDA: 76041482622.06.salt53_1ec0bcc307b58 X-HE-Tag: salt53_1ec0bcc307b58 X-Filterd-Recvd-Size: 3347 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Mon, 14 Oct 2019 06:56:51 +0000 (UTC) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Oct 2019 23:56:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,295,1566889200"; d="scan'208";a="207912597" Received: from zhangyu-optiplex-9020.bj.intel.com (HELO localhost) ([10.238.135.148]) by fmsmga001.fm.intel.com with ESMTP; 13 Oct 2019 23:56:46 -0700 Date: Mon, 14 Oct 2019 14:47:53 +0800 From: Yu Zhang To: Rick Edgecombe Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, linux-mm@kvack.org, luto@kernel.org, peterz@infradead.org, dave.hansen@intel.com, pbonzini@redhat.com, sean.j.christopherson@intel.com, keescook@chromium.org, kristen@linux.intel.com, deneen.t.dock@intel.com Subject: Re: [RFC PATCH 01/13] kvm: Enable MTRR to work with GFNs with perm bits Message-ID: <20191014064753.xv365y6oowmh6ho7@linux.intel.com> References: <20191003212400.31130-1-rick.p.edgecombe@intel.com> <20191003212400.31130-2-rick.p.edgecombe@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191003212400.31130-2-rick.p.edgecombe@intel.com> User-Agent: NeoMutt/20180622-66-b94505 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Oct 03, 2019 at 02:23:48PM -0700, Rick Edgecombe wrote: > Mask gfn by maxphyaddr in kvm_mtrr_get_guest_memory_type so that the > guests view of gfn is used when high bits of the physical memory are > used as extra permissions bits. This supports the KVM XO feature. > > TODO: Since MTRR is emulated using EPT permissions, the XO version of > the gpa range will not inherrit the MTRR type with this implementation. > There shouldn't be any legacy use of KVM XO, but hypothetically it could > interfere with the uncacheable MTRR type. > > Signed-off-by: Rick Edgecombe > --- > arch/x86/kvm/mtrr.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c > index 25ce3edd1872..da38f3b83e51 100644 > --- a/arch/x86/kvm/mtrr.c > +++ b/arch/x86/kvm/mtrr.c > @@ -621,6 +621,14 @@ u8 kvm_mtrr_get_guest_memory_type(struct kvm_vcpu *vcpu, gfn_t gfn) > const int wt_wb_mask = (1 << MTRR_TYPE_WRBACK) > | (1 << MTRR_TYPE_WRTHROUGH); > > + /* > + * Handle situations where gfn bits are used as permissions bits by > + * masking KVMs view of the gfn with the guests physical address bits > + * in order to match the guests view of physical address. For normal > + * situations this will have no effect. > + */ > + gfn &= (1ULL << (cpuid_maxphyaddr(vcpu) - PAGE_SHIFT)); > + Won't this break the MTRR calculation for normal gfns? Are you suggesting use the same MTRR value for the XO range as the normal one's? If so, may be we should use: if (guest_cpuid_has(vcpu, X86_FEATURE_KVM_XO)) gfn &= ~(1ULL << (cpuid_maxphyaddr(vcpu) - PAGE_SHIFT)); > start = gfn_to_gpa(gfn); > end = start + PAGE_SIZE; > > -- > 2.17.1 > B.R. Yu