Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp3275805imw; Mon, 18 Jul 2022 05:24:46 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sb0jioZu9dy+uhBMtwwHyUgmA3I/cmcu4yLgFWtHtl+6btmmNNYhjfJ7N2VlW0eZZ22ZNm X-Received: by 2002:a05:6870:e9a0:b0:10c:a859:3364 with SMTP id r32-20020a056870e9a000b0010ca8593364mr14532589oao.297.1658147086554; Mon, 18 Jul 2022 05:24:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658147086; cv=none; d=google.com; s=arc-20160816; b=Upjr5CjJMkJ1LHEyutbizRa6+P2bAigOZfS4766BTVUbVdcUjfcyjbpGV+bci6sAXA oR6U3by+nEdWHZrN7BwjVX/6eg+JPYN40MBrme8WcJK4V/+MOcqLipYabbeP2ql1DTDj oyqnU36wgDAtqSa8dFXn2d0doUd9496hC0tcnh5hubyf/DXw9AZh9Vo14FznSsIEisMo cmZJ4RgK75PzWslvr3lfW4Xl5Zsqb1HfchaGhFG2+fJtmmR5m3zRRJryKYFHkeCsH7dw zOBY0CMeWytOoj1Vlc9c+D30VyKUk6/QD+gWQMn47d7PFfnzP36BUQgHiT834azFy6ni uo8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=/PFkIF1rv5Mk0FbpMT60my0l/eja9lFVjvdGHcn5kQ8=; b=TT8MuwKp84n3D6YPv3P1oa9vpXYvjYYAINTfjYIYE3PMISO4o/38StkR7BsSToF83M Nu4nnS3qRUbySrjuhODH3qtZdB+GxUA+/2hMe9S2vCD4/JFYbCN7AxvHOvwmW8xyeQKO jFHJ4ItOMq47GcO0Uib06cUKn/fCkJPErQOrJJrfHu+5pz0i05KYVFKHUOE5+vP2jg+z QMdQOu7Eubcf7GaBVRVLCsW/E4WwdgKNuiCMOEf32WZXPbgLCWo4oHZkkLwxk4DaUaQ3 /4o3UCq8o1U8LG5mNzW/ccj7dus5zqJy1HdkNBkcrQXwqg5fcP7SNI3aWNt4J4aBeJcB arIw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=cQuvmA+q; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d1-20020a05683025c100b00616cc0c301csi10181739otu.17.2022.07.18.05.24.32; Mon, 18 Jul 2022 05:24:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=cQuvmA+q; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234768AbiGRMJU (ORCPT + 99 others); Mon, 18 Jul 2022 08:09:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55428 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234753AbiGRMJQ (ORCPT ); Mon, 18 Jul 2022 08:09:16 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 776A42494C for ; Mon, 18 Jul 2022 05:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1658146116; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/PFkIF1rv5Mk0FbpMT60my0l/eja9lFVjvdGHcn5kQ8=; b=cQuvmA+qXJwmOQE6Xr4rAa95239qQ3aw7YXcC69e/1RNECUp5dCuodWXJ5D4uEO43AC8JO BkHLhaqW8sR7+iM7ddSOZU4o8exZJW1Z8YUIgHGAqqUsK+bBpgF53nmO6Lq0SERrCSInE9 v276rBn0/pxlAPyJsraqMmgnA3LGGfE= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-641-ABb9CX5APtauTJNwa8G-_w-1; Mon, 18 Jul 2022 08:08:35 -0400 X-MC-Unique: ABb9CX5APtauTJNwa8G-_w-1 Received: by mail-qk1-f199.google.com with SMTP id v13-20020a05620a0f0d00b006b5f0ec742eso1186203qkl.2 for ; Mon, 18 Jul 2022 05:08:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=/PFkIF1rv5Mk0FbpMT60my0l/eja9lFVjvdGHcn5kQ8=; b=ELsPOwLCrAaGEngPGWyit7afw0eqe8JDKQwHOs0Dqq4BfhpEF3ukUBfB8pP+2rrcKq tZ4/yGg8ZnR7moPT1XtRBXhOKSoaQpOnaxptyKieRmmHhRR8twsDqlCro6zelmiiXZ4w ctv3FgTY8ZCBwr2v/yDD85dzHW7kwBNsRnJj5pnjUUdmcPLEbrYRUCpY/YCSoq22wJWd OktaJqxNtJpsAT2Qbh3emLmpM26UlvLS9dV9Qmrk+cneAFEJT7MBvt/TF+Kql4M3BcvT rV1lYCSgoMHHXqWUrbPYbqxuLV+1Y6GusjJJ3J5KheP8DbFOx8tXB5HOk+p/leUvG+Jq lz5A== X-Gm-Message-State: AJIora87Y48gcW/PdEW7EAV9u7Bb2vLN9VwfMx8d+u7tv5624fmT4JFU XyaBjIQ841Y1BXln0494vugApQboOgMGBE4fhDCbXqpST8h6b/HvOjUa71wlyUQWyQdoc0F1sc/ IbKJCNil+ipu0GdAfH4m6WD0s X-Received: by 2002:a05:622a:2c3:b0:31e:e18f:4fbd with SMTP id a3-20020a05622a02c300b0031ee18f4fbdmr9050223qtx.641.1658146114011; Mon, 18 Jul 2022 05:08:34 -0700 (PDT) X-Received: by 2002:a05:622a:2c3:b0:31e:e18f:4fbd with SMTP id a3-20020a05622a02c300b0031ee18f4fbdmr9050195qtx.641.1658146113644; Mon, 18 Jul 2022 05:08:33 -0700 (PDT) Received: from [10.35.4.238] (bzq-82-81-161-50.red.bezeqint.net. [82.81.161.50]) by smtp.gmail.com with ESMTPSA id n7-20020a05620a294700b006b5bc40a220sm11875602qkp.51.2022.07.18.05.08.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Jul 2022 05:08:33 -0700 (PDT) Message-ID: <580a46b4623309474bb3207ea994eb9b5a3603a7.camel@redhat.com> Subject: Re: [PATCH 3/4] KVM: x86/mmu: Add shadow mask for effective host MTRR memtype From: Maxim Levitsky To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org Date: Mon, 18 Jul 2022 15:08:30 +0300 In-Reply-To: <20220715230016.3762909-4-seanjc@google.com> References: <20220715230016.3762909-1-seanjc@google.com> <20220715230016.3762909-4-seanjc@google.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 (3.40.4-5.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2022-07-15 at 23:00 +0000, Sean Christopherson wrote: > Add shadow_memtype_mask to capture that EPT needs a non-zero memtype mask > instead of relying on TDP being enabled, as NPT doesn't need a non-zero > mask.  This is a glorified nop as kvm_x86_ops.get_mt_mask() returns zero > for NPT anyways. > > No functional change intended. > > Signed-off-by: Sean Christopherson > --- >  arch/x86/kvm/mmu/spte.c | 21 ++++++++++++++++++--- >  arch/x86/kvm/mmu/spte.h |  1 + >  2 files changed, 19 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/kvm/mmu/spte.c b/arch/x86/kvm/mmu/spte.c > index fb1f17504138..7314d27d57a4 100644 > --- a/arch/x86/kvm/mmu/spte.c > +++ b/arch/x86/kvm/mmu/spte.c > @@ -33,6 +33,7 @@ u64 __read_mostly shadow_mmio_value; >  u64 __read_mostly shadow_mmio_mask; >  u64 __read_mostly shadow_mmio_access_mask; >  u64 __read_mostly shadow_present_mask; > +u64 __read_mostly shadow_memtype_mask; >  u64 __read_mostly shadow_me_value; >  u64 __read_mostly shadow_me_mask; >  u64 __read_mostly shadow_acc_track_mask; > @@ -161,10 +162,10 @@ bool make_spte(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp, >   >         if (level > PG_LEVEL_4K) >                 spte |= PT_PAGE_SIZE_MASK; > -       if (tdp_enabled) > + > +       if (shadow_memtype_mask) >                 spte |= static_call(kvm_x86_get_mt_mask)(vcpu, gfn, > -                       kvm_is_mmio_pfn(pfn)); > - > +                                                        kvm_is_mmio_pfn(pfn)); >         if (host_writable) >                 spte |= shadow_host_writable_mask; >         else > @@ -391,6 +392,13 @@ void kvm_mmu_set_ept_masks(bool has_ad_bits, bool has_exec_only) >         shadow_nx_mask          = 0ull; >         shadow_x_mask           = VMX_EPT_EXECUTABLE_MASK; >         shadow_present_mask     = has_exec_only ? 0ull : VMX_EPT_READABLE_MASK; > +       /* > +        * EPT overrides the host MTRRs, and so KVM must program the desired > +        * memtype directly into the SPTEs.  Note, this mask is just the mask > +        * of all bits that factor into the memtype, the actual memtype must be > +        * dynamically calculated, e.g. to ensure host MMIO is mapped UC. > +        */ > +       shadow_memtype_mask     = VMX_EPT_MT_MASK | VMX_EPT_IPAT_BIT; >         shadow_acc_track_mask   = VMX_EPT_RWX_MASK; >         shadow_host_writable_mask = EPT_SPTE_HOST_WRITABLE; >         shadow_mmu_writable_mask  = EPT_SPTE_MMU_WRITABLE; > @@ -441,6 +449,13 @@ void kvm_mmu_reset_all_pte_masks(void) >         shadow_nx_mask          = PT64_NX_MASK; >         shadow_x_mask           = 0; >         shadow_present_mask     = PT_PRESENT_MASK; > + > +       /* > +        * For shadow paging and NPT, KVM uses PAT entry '0' to encode WB > +        * memtype in the SPTEs, i.e. relies on host MTRRs to provide the > +        * correct memtype (WB is the "weakest" memtype). > +        */ > +       shadow_memtype_mask     = 0; >         shadow_acc_track_mask   = 0; >         shadow_me_mask          = 0; >         shadow_me_value         = 0; > diff --git a/arch/x86/kvm/mmu/spte.h b/arch/x86/kvm/mmu/spte.h > index ba3dccb202bc..cabe3fbb4f39 100644 > --- a/arch/x86/kvm/mmu/spte.h > +++ b/arch/x86/kvm/mmu/spte.h > @@ -147,6 +147,7 @@ extern u64 __read_mostly shadow_mmio_value; >  extern u64 __read_mostly shadow_mmio_mask; >  extern u64 __read_mostly shadow_mmio_access_mask; >  extern u64 __read_mostly shadow_present_mask; > +extern u64 __read_mostly shadow_memtype_mask; >  extern u64 __read_mostly shadow_me_value; >  extern u64 __read_mostly shadow_me_mask; >   So if I understand correctly: VMX: - host MTRRs are ignored. - all *host* mmio ranges (can only be VFIO's pci BARs), are mapped UC in EPT, but guest can override this with its PAT to WC) - all regular memory is mapped WB + guest PAT ignored unless there is noncoherent dma, (an older Intel's IOMMU? I think current Intel's IOMMLU are coherent?) - In case of noncoherent dma guest MTRRs and PAT are respected. SVM: - host MTRRs are respected, and can enforce UC on *host* mmio areas. - WB is always used in NPT, *always*, however NPT doesn't have the 'IPAT' bit, so the guest is free to overrride it for its its MMIO areas to any memory type as it wishes, using its own PAT, and we do allow the guest to change IA32_PAT to any value it wishes to. (e.g VFIO's PCI bars, memory which a VFIO devices needs to access, etc) (This reminds me that PAT is somewhat broken in regard to nesting, we ignore L2's PAT) With all this said, it makes sense. Reviewed-by: Maxim Levitsky Best regards, Maxim Levitsky