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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7B489C77B7C for ; Thu, 11 May 2023 23:03:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239402AbjEKXD2 (ORCPT ); Thu, 11 May 2023 19:03:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54048 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239296AbjEKXDX (ORCPT ); Thu, 11 May 2023 19:03:23 -0400 Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 065B410F3 for ; Thu, 11 May 2023 16:03:19 -0700 (PDT) Received: by mail-yb1-xb49.google.com with SMTP id 3f1490d57ef6-ba2d0b391d3so12246237276.2 for ; Thu, 11 May 2023 16:03:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1683846198; x=1686438198; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=G7in9pHI8f4PbQncUNnm7irUkPJSlHoe9VFQrVjPC7s=; b=tlr7jb7AGBJLC1tGipYMA+NIE4W3qmlQdmY6GWrzLWsGWnOTLjaPHHlQG+JucDh8Qh Q+VUON7noOWe1bBTJLFWP8puzEqijn6x7iGqKtaf9KUTnJocCwIq8bQ4zF4ncz61ZUGV nIHRFyH+MjsY730vxId7VHLbcvyRGoDaRelSW10OrS6ersh1m09qWmIwdCDpEBmNK6ei d6zSU5NXO5rdsbAuzikE+DvT55dlDlrAAaWpeQnkwAGG0fYAdvmwXqV5dGWS3kPWcdMF u2iSGm/rtbBHvcFaFQcphfbZ8bqMKYu0jmywqpH7Ckh7xisCgK+GQqSuL5CH54Cv6zlp sNvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683846198; x=1686438198; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=G7in9pHI8f4PbQncUNnm7irUkPJSlHoe9VFQrVjPC7s=; b=Xn0tL0oBGhHxdg5aAXX7zKphsBzoxH9W8wRlVzI3QSDgHGe1mYGFJOb9Ba58a+N1hx CHJh4x0paMCWcI+rNBsPrCQz6z0tjjrlEXZZy7c6ptMKR3EY6npennHC6rS4WUY12jSM RZgcJ8padxaAQR1wpOq5N+quHu2RfOkXIR7gsrxB8xyLcVg5MYOJgV2IFqratxczcGHP l0EcgbfyJLkcxUkoS6r5eOi9IRIWqPYbK+LR9YMyFh1wRrJ6ExRdvqbNZFqxv++Sp/YU uqJVK0RWAhHQNDX4fuktd+n8YjYbweZ3mP3eUJKSyZWVhsLXcnKp4qy0A7OoHxQuSKYM FTnQ== X-Gm-Message-State: AC+VfDxJMmVHiGT9KfgaYlS71hKazuDkgM4rgbP8tdGGrY+pzk5RMrv3 VyFfZMrb5SXju4R1dd7+UzxUGNFY9so= X-Google-Smtp-Source: ACHHUZ43vzdgen2cveEeuKc+w92V7EeydHPKvEDKQRhBlrxAUEbdBd/WS3cmrriiVF0Dek+gyLX5N7OBccE= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:21c5:0:b0:ba6:e7ee:bb99 with SMTP id h188-20020a2521c5000000b00ba6e7eebb99mr976041ybh.12.1683846198249; Thu, 11 May 2023 16:03:18 -0700 (PDT) Date: Thu, 11 May 2023 16:03:16 -0700 In-Reply-To: Mime-Version: 1.0 References: <20230503182852.3431281-1-seanjc@google.com> <20230503182852.3431281-3-seanjc@google.com> <06715227566b520d4a445466f091dc28a0b8cd95.camel@intel.com> Message-ID: Subject: Re: [PATCH 2/5] KVM: SVM: Use kvm_pat_valid() directly instead of kvm_mtrr_valid() From: Sean Christopherson To: Kai Huang Cc: "kvm@vger.kernel.org" , "pbonzini@redhat.com" , "guoke@uniontech.com" , "linux-kernel@vger.kernel.org" , "haiwenyao@uniontech.com" Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 05, 2023, Kai Huang wrote: > On Thu, 2023-05-04 at 08:34 -0700, Sean Christopherson wrote: > > On Wed, May 03, 2023, Kai Huang wrote: > > > > for better or worse, KVM doesn't apply the "zap > > > > SPTEs" logic to guest PAT changes when the VM has a passthrough device > > > > with non-coherent DMA. > > > > > > Is it a bug? > > > > No. KVM's MTRR behavior is using a heuristic to try not to break the VM: if the > > VM has non-coherent DMA, then honor UC mapping in the MTRRs as such mappings may > > be coverage the non-coherent DMA. > > > > From vmx_get_mt_mask(): > > > > /* We wanted to honor guest CD/MTRR/PAT, but doing so could result in > > * memory aliases with conflicting memory types and sometimes MCEs. > > * We have to be careful as to what are honored and when. > > > > The PAT is problematic because it is referenced via the guest PTEs, versus the > > MTRRs being tied to the guest physical address, e.g. different virtual mappings > > for the same physical address can yield different memtypes via the PAT. My head > > hurts just thinking about how that might interact with shadow paging :-) > > > > Even the MTRRs are somewhat sketchy because they are technically per-CPU, i.e. > > two vCPUs could have different memtypes for the same physical address. But in > > practice, sane software/firmware uses consistent MTRRs across all CPUs. > > Agreed on all above odds. > > But I think the answer to my question is actually we simply don't _need_ to zap > SPTEs (with non-coherent DMA) when guest's IA32_PAT is changed: > > 1) If EPT is enabled, IIUC guest's PAT is already horned. VMCS's GUEST_IA32_PAT > always reflects the IA32_PAT that guest wants to set. EPT's memtype bits are > set according to guest's MTRR. That means guest changing IA32_PAT doesn't need > to zap EPT PTEs as "EPT PTEs essentially only replaces guest's MTRRs". Ah, yes, you're correct. I thought KVM _always_ set the "ignore guest PAT" bit in the EPT PTEs, but KVM honors guest PAT when non-coherent DMA is present and CR0.CD=0. > 2) If EPT is disabled, looking at the code, if I read correctly, the > 'shadow_memtype_mask' is 0 for Intel, in which case KVM won't try to set any PAT > memtype bit in shadow MMU PTE, which means the true PAT memtype is always WB and > guest's memtype is never horned (guest's MTRRs are also never actually used by > HW), which should be fine I guess?? My brain refused to go further :) Yep. It's entirely possible that VT-d without snoop control simply doesn't work with shadow paging, but no one has ever cared. > But anyway back to my question, I think "changing guest's IA32_PAT" shouldn't > result in needing to "zap SPTEs".