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=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS 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 20E94C43381 for ; Fri, 22 Mar 2019 10:03:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E15D52070D for ; Fri, 22 Mar 2019 10:03:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1553248985; bh=IVPYKINU/4mmqKxneHxMEG5qunVVIxqHqLH8GhBddaU=; h=Subject:To:Cc:From:Date:List-ID:From; b=qoftHR560ZyY9POjKagYgc+snJQ+DKEdFiNMzR+BQ9VVypmRPa9mZ5pk6rpYfcikp CwV3vUxXEGQp/tgye+VowlRRhff5b1J1FkrKmQqWWnlzdsB7PpRoasI9c6uki8j34u 6EyHooUzazgvJ8fOkxedx7PalkMFfRwln371LjwE= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727979AbfCVKDE (ORCPT ); Fri, 22 Mar 2019 06:03:04 -0400 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:46985 "EHLO wout1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727957AbfCVKDE (ORCPT ); Fri, 22 Mar 2019 06:03:04 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 0F7FE46D2; Fri, 22 Mar 2019 06:03:02 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Fri, 22 Mar 2019 06:03:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=AcGha3 JxByH3qCAWYc4kRqsxi8bQiynZ1KebwSvNOs8=; b=0YIs/W115ra/bhvLUBMxGf z4u0nEsGzeMMhtI71hwT/1FsWGov4eq1Gd5AvRTdBHkBujwmdg3ZyPOJTXUqywLa /r9ihJecSuiskYL56vP2qjkI3lyU2ziwbOtGZpw7MvpbesMWqL+n5C8R9U+k4WZI Y6b2LRJ1NsLAMM7VosLsY1pF+fYq71pWq67mFTd3p0mc6xQfxQlXLSWaVbEIwYRQ nzHcGJvD+1JltGbdzDKEnVi7mmIQbLXpMTSjRMkXK09jzFqlkd4dPmQLdB0LnSie Xt24Sp9Q0ZyVJvjNIEY8xG9JcUBA3iJvpB9pBMY/vxsv2/yKzOIn9BmDW3EXLulw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrjedugddutdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvhfffkfggtgfgsehtkeertddttd flnecuhfhrohhmpeeoghhrvghgkhhhsehlihhnuhigfhhouhhnuggrthhiohhnrdhorhhg qeenucfkphepkeefrdekiedrkeelrddutdejnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hgrhgvgheskhhrohgrhhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) by mail.messagingengine.com (Postfix) with ESMTPA id F272710312; Fri, 22 Mar 2019 06:03:01 -0400 (EDT) Subject: FAILED: patch "[PATCH] KVM: x86/mmu: Do not cache MMIO accesses while memslots are" failed to apply to 4.9-stable tree To: sean.j.christopherson@intel.com, pbonzini@redhat.com, stable@vger.kernel.org Cc: From: Date: Fri, 22 Mar 2019 11:03:00 +0100 Message-ID: <1553248980227165@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From ddfd1730fd829743e41213e32ccc8b4aa6dc8325 Mon Sep 17 00:00:00 2001 From: Sean Christopherson Date: Tue, 5 Feb 2019 13:01:13 -0800 Subject: [PATCH] KVM: x86/mmu: Do not cache MMIO accesses while memslots are in flux When installing new memslots, KVM sets bit 0 of the generation number to indicate that an update is in-progress. Until the update is complete, there are no guarantees as to whether a vCPU will see the old or the new memslots. Explicity prevent caching MMIO accesses so as to avoid using an access cached from the old memslots after the new memslots have been installed. Note that it is unclear whether or not disabling caching during the update window is strictly necessary as there is no definitive documentation as to what ordering guarantees KVM provides with respect to updating memslots. That being said, the MMIO spte code does not allow reusing sptes created while an update is in-progress, and the associated documentation explicitly states: We do not want to use an MMIO sptes created with an odd generation number, ... If KVM is unlucky and creates an MMIO spte while the low bit is 1, the next access to the spte will always be a cache miss. At the very least, disabling the per-vCPU MMIO cache during updates will make its behavior consistent with the MMIO spte behavior and documentation. Fixes: 56f17dd3fbc4 ("kvm: x86: fix stale mmio cache bug") Cc: Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h index 224cd0a47568..20ede17202bf 100644 --- a/arch/x86/kvm/x86.h +++ b/arch/x86/kvm/x86.h @@ -181,6 +181,11 @@ static inline bool emul_is_noncanonical_address(u64 la, static inline void vcpu_cache_mmio_info(struct kvm_vcpu *vcpu, gva_t gva, gfn_t gfn, unsigned access) { + u64 gen = kvm_memslots(vcpu->kvm)->generation; + + if (unlikely(gen & 1)) + return; + /* * If this is a shadow nested page table, the "GVA" is * actually a nGPA. @@ -188,7 +193,7 @@ static inline void vcpu_cache_mmio_info(struct kvm_vcpu *vcpu, vcpu->arch.mmio_gva = mmu_is_nested(vcpu) ? 0 : gva & PAGE_MASK; vcpu->arch.access = access; vcpu->arch.mmio_gfn = gfn; - vcpu->arch.mmio_gen = kvm_memslots(vcpu->kvm)->generation; + vcpu->arch.mmio_gen = gen; } static inline bool vcpu_match_mmio_gen(struct kvm_vcpu *vcpu)