From nobody Mon Feb 9 13:01:48 2026 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A32BE16FF5E for ; Sat, 9 Mar 2024 01:09:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.202 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709946584; cv=none; b=MRp/1NogShvHydZjM19lxFAkeFW6jh7Ss3tTpbywsj30DbKqTwWRlEEIP3za8P5ihecBzGWYUb/4SlPokUkWQ8BNLGH6OzREvo+P2FnWFEBRNwAsAiqN3628mLEktBiT/0Yg8f/bHzblK0dx+8sp1AYG719HMyNyia5hmn2iy1o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709946584; c=relaxed/simple; bh=56l3qV2E5YVzJsQoDii+3QTD/H2MArANKbGDDmYY5so=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=NhktvjQcoCZQe26ZYZTDlTWtSXCVkosI4amFEbq2o+voYK67qiwtxzqpPoUzYq5VT/UfY7XI8vIkla30ziIOl/eKzk6J4xoOCqwSrk4IBihtgFIjbNGQcEYXFvPC6SUlxneT6kXc7I4TOpCNwE3THvyi8iMxegF/fCcwG6wedqA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=oafOSacE; arc=none smtp.client-ip=209.85.214.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="oafOSacE" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-1dcfb65e143so27368195ad.1 for ; Fri, 08 Mar 2024 17:09:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1709946582; x=1710551382; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=GtHnwYnueCwfZNon9qMZcoozTyyxAoukw9Anit3u7vs=; b=oafOSacEr89Bk3J5cq5t8nmdq41sepaBeNz8HU5f5vzRDN8BBvq4l/eaSDWpShrH5r OdvotphgRMvgz9qyqEspKdusQ0VPw74L0YH28DLOGSaaLOj5CJM/1sPk/lZ9ooGJCw9h IJ2pany68EbuPaO6bysK6e02QYsvuV0iLRxwBWe4Srf+K4AWuhSUbn2G/7kyYMvu5hN9 pMIIp+kdWjINVBf107hWv/xjKMTKCDvz8sMSu04LOUb+9UsC4FPWTA2hQC2VNpNFSWEq 1Ld0U9w1kv4WsYmxWs8NqKNRxR1uidiuqEq3rRXVo0ELYGWJX38zh9ZSHXiBM1yvk+f2 0sLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709946582; x=1710551382; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GtHnwYnueCwfZNon9qMZcoozTyyxAoukw9Anit3u7vs=; b=A2OKR1S7B7hCCTC6R2ayPSDwtiH8R7TJEZamK6Y6XySFCJjJnugY9di3g5TrvomND2 pFIkrxHtLyV/mbjqB3PQgUq5XgY7ZqG4vF+j346p02xKG68fpdS4lgueVuvoBa4EQwzj rKdUpTbePpDt2PeYCdG9AAAv7kbLoiBZ5MB74aHDBBisPoFAIfEa9TXrkqp8gijo96yF OAKham5P7icb5G5YXDqI1cJ0/kqIvVSm9p4ZMRP3RminP0WwclWLlqmH8yGrCJuL7EwR kPn8pBNvkxJtJV4sscvtvnu+sZ1R83EfNaUnrJFDPUDvsl5jqOJc85jgp/hOJWWoPluC B0KQ== X-Forwarded-Encrypted: i=1; AJvYcCVemNWKtxf2rdP1xFQPO4AMnspqBz76H17Yqy3aX5IXtBE/y9nbO84LV7j2/zLJtZK1slQB6a3mNxNP7aH2MZPxjsaEVNkSutKBt9D2 X-Gm-Message-State: AOJu0YxLe8t+ohHBczf/bELEiSQOwFB5P467ynLUUd7+dlEh3Ca64fg6 j6mCpWoPS9NA8Xf2F1+H1MzQOsk75e+I+Dxq05V+aL3T7+SS7zrtJby/goGmugDwyp/8z9Q9Cr7 RRQ== X-Google-Smtp-Source: AGHT+IFcax0jBBlFuP0Y7Y0xcnqeeeJ7WiLfIus4V6pgH0oz7sMxr9KM4LErcwOoG2CptIvrKKjnya25r1o= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:d4d0:b0:1dc:8da7:9d0b with SMTP id o16-20020a170902d4d000b001dc8da79d0bmr5416plg.9.1709946581833; Fri, 08 Mar 2024 17:09:41 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 8 Mar 2024 17:09:26 -0800 In-Reply-To: <20240309010929.1403984-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20240309010929.1403984-1-seanjc@google.com> X-Mailer: git-send-email 2.44.0.278.ge034bb2e1d-goog Message-ID: <20240309010929.1403984-3-seanjc@google.com> Subject: [PATCH 2/5] KVM: VMX: Drop support for forcing UC memory when guest CR0.CD=1 From: Sean Christopherson To: Paolo Bonzini , Sean Christopherson , Lai Jiangshan , "Paul E. McKenney" , Josh Triplett Cc: kvm@vger.kernel.org, rcu@vger.kernel.org, linux-kernel@vger.kernel.org, Kevin Tian , Yan Zhao , Yiwei Zhang Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Drop KVM's emulation of CR0.CD=3D1 on Intel CPUs now that KVM no longer honors guest MTRR memtypes, as forcing UC memory for VMs with non-coherent DMA only makes sense if the guest is using something other than PAT to configure the memtype for the DMA region. Furthermore, KVM has forced WB memory for CR0.CD=3D1 since commit fb279950ba02 ("KVM: vmx: obey KVM_QUIRK_CD_NW_CLEARED"), and no known VMM in existence disables KVM_X86_QUIRK_CD_NW_CLEARED, let alone does so with non-coherent DMA. Lastly, commit fb279950ba02 ("KVM: vmx: obey KVM_QUIRK_CD_NW_CLEARED") was from the same author as commit b18d5431acc7 ("KVM: x86: fix CR0.CD virtualization"), and followed by a mere month. I.e. forcing UC memory was likely the result of code inspection or perhaps misdiagnosed failures, and not the necessitate by a concrete use case. Update KVM's documentation to note that KVM_X86_QUIRK_CD_NW_CLEARED is now AMD-only, and to take an erratum for lack of CR0.CD virtualization on Intel. Signed-off-by: Sean Christopherson --- Documentation/virt/kvm/api.rst | 6 +++++- Documentation/virt/kvm/x86/errata.rst | 19 +++++++++++++++---- arch/x86/kvm/vmx/vmx.c | 4 ---- arch/x86/kvm/x86.c | 6 ------ 4 files changed, 20 insertions(+), 15 deletions(-) diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 0b5a33ee71ee..e85edd26ea5a 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -7946,7 +7946,11 @@ The valid bits in cap.args[0] are: When this quirk is disabled, the reset= value is 0x10000 (APIC_LVT_MASKED). =20 - KVM_X86_QUIRK_CD_NW_CLEARED By default, KVM clears CR0.CD and CR0.= NW. + KVM_X86_QUIRK_CD_NW_CLEARED By default, KVM clears CR0.CD and CR0.= NW on + AMD CPUs to workaround buggy guest fir= mware + that runs in perpetuity with CR0.CD, i= .e. + with caches in "no fill" mode. + When this quirk is disabled, KVM does = not change the value of CR0.CD and CR0.NW. =20 diff --git a/Documentation/virt/kvm/x86/errata.rst b/Documentation/virt/kvm= /x86/errata.rst index 1b70bad7325e..4116045a8744 100644 --- a/Documentation/virt/kvm/x86/errata.rst +++ b/Documentation/virt/kvm/x86/errata.rst @@ -51,7 +51,18 @@ matching the target APIC ID receive the interrupt). =20 MTRRs ----- -KVM does not virtualization guest MTRR memory types. KVM emulates accesse= s to -MTRR MSRs, i.e. {RD,WR}MSR in the guest will behave as expected, but KVM d= oes -not honor guest MTRRs when determining the effective memory type, and inst= ead -treats all of guest memory as having Writeback (WB) MTRRs. \ No newline at end of file +KVM does not virtualize guest MTRR memory types. KVM emulates accesses to= MTRR +MSRs, i.e. {RD,WR}MSR in the guest will behave as expected, but KVM does n= ot +honor guest MTRRs when determining the effective memory type, and instead +treats all of guest memory as having Writeback (WB) MTRRs. + +CR0.CD +------ +KVM does not virtualize CR0.CD on Intel CPUs. Similar to MTRR MSRs, KVM +emulates CR0.CD accesses so that loads and stores from/to CR0 behave as +expected, but setting CR0.CD=3D1 has no impact on the cachaeability of gue= st +memory. + +Note, this erratum does not affect AMD CPUs, which fully virtualize CR0.CD= in +hardware, i.e. put the CPU caches into "no fill" mode when CR0.CD=3D1, eve= n when +running in the guest. \ No newline at end of file diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 66bf79decdad..17a8e4fdf9c4 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -7612,10 +7612,6 @@ static u8 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn= _t gfn, bool is_mmio) if (!kvm_arch_has_noncoherent_dma(vcpu->kvm)) return (MTRR_TYPE_WRBACK << VMX_EPT_MT_EPTE_SHIFT) | VMX_EPT_IPAT_BIT; =20 - if (kvm_read_cr0_bits(vcpu, X86_CR0_CD) && - !kvm_check_has_quirk(vcpu->kvm, KVM_X86_QUIRK_CD_NW_CLEARED)) - return (MTRR_TYPE_UNCACHABLE << VMX_EPT_MT_EPTE_SHIFT) | VMX_EPT_IPAT_BI= T; - return (MTRR_TYPE_WRBACK << VMX_EPT_MT_EPTE_SHIFT); } =20 diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 2a38b4c26d35..276ae56dd888 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -960,12 +960,6 @@ void kvm_post_set_cr0(struct kvm_vcpu *vcpu, unsigned = long old_cr0, unsigned lon =20 if ((cr0 ^ old_cr0) & KVM_MMU_CR0_ROLE_BITS) kvm_mmu_reset_context(vcpu); - - if (((cr0 ^ old_cr0) & X86_CR0_CD) && - kvm_mmu_may_ignore_guest_pat() && - kvm_arch_has_noncoherent_dma(vcpu->kvm) && - !kvm_check_has_quirk(vcpu->kvm, KVM_X86_QUIRK_CD_NW_CLEARED)) - kvm_zap_gfn_range(vcpu->kvm, 0, ~0ULL); } EXPORT_SYMBOL_GPL(kvm_post_set_cr0); =20 --=20 2.44.0.278.ge034bb2e1d-goog