Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4681158pxj; Wed, 12 May 2021 10:45:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwv81eYtNvK1nnX3W/ALmaWcYdka8MZo01eyztnizGmY0H18ZNtONDHWmHb18zYU35uI+Ir X-Received: by 2002:a05:6402:694:: with SMTP id f20mr45112434edy.93.1620841391614; Wed, 12 May 2021 10:43:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620841391; cv=none; d=google.com; s=arc-20160816; b=uVuUam8Eb0kQ6wrcRw7KhNXcWTZq0utUl1psX1Z5UT8iDIa6V0fIZW23wRgPz6GIJ/ KvrXhUthT/yYTMVVakNxMkw/NGsm3XtokKgooWysGH76Io7ursh2C8Ae1J4zq0NM/n4v SN2/iz0VYuCmGS0RMObl0shwlMyAgU7xFppmFkq//KYfcBIJvllT3ZIpfBrg4GdvPPwF fktpahd0ELFYYGLSv5TzCXAWUyEOeF/caTf/XrYBCYroF37Vg8GmMxelNeI6kioVNt44 dNwxmf44moh8OZ6u56ZwNjW1NSSG/ISCV0L+BJaFTuZim7BUwYGock/CIlu9Dz9F6nss 46Xg== 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:message-id:date:subject:cc:to :from:dkim-signature; bh=ODi1YwR5ZyLJH7SU0prgSLpMD6+cQ3lTZjfeSvjuwbA=; b=v1AgkwBB13iGpD8YYHc4KpxpqmKVS6T9nUcYRo+FETGN9Fq53Q9WWQM2f+fzattaas Ta1TcSnfoBmpYBwQF8RUqo9L+S0nBOBBlNCWlDos2HhUXJaczedyvLz+3wm1PRFcOe6g /yXSF2DbLCPcc7WhqBxVH0mfmJxUwYs5xHuzh1hzgI4EOikc3LlrWREKheOF+81lDA6B GLU0bPDBlS7n4NSiubtASL5ldo7vwTMN+VWVTAYlUSerXR1bi0KEs9FnYPbTJk/3npK2 SMw8/6snlTbceJcS4O2hKIL/tv1LnzmCkFN3nhKAVBlnzHJfMJDUXV+EaHtp0elVkUsM CVaQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=qFlAbv7e; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n15si266388edy.288.2021.05.12.10.42.44; Wed, 12 May 2021 10:43:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=qFlAbv7e; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348948AbhELRjt (ORCPT + 99 others); Wed, 12 May 2021 13:39:49 -0400 Received: from mail.kernel.org ([198.145.29.99]:49402 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236730AbhELQMa (ORCPT ); Wed, 12 May 2021 12:12:30 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 0D65A61D44; Wed, 12 May 2021 15:41:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1620834070; bh=6HOkzmM+NRX+mGTooWchTjVrwWbV1Dj2SYoRxg1wBxQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qFlAbv7eojSjyMjTJ0DPGQ7rEewJh3bWswTdwPasB3IuMSJrJygd1/TZLVLCs5+pA RVB1d/uB88RjeVXFvYoeip2CyToOt7ZDbTM42jnD0Ykdyn8b3TEMsu3JvZArKO8LQ7 o+3z7gtrp+k5HvSyOsJoIeD31Fw3GE6hCH5RhT/E= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ben Gardon , Sean Christopherson , Paolo Bonzini , Sasha Levin Subject: [PATCH 5.11 396/601] KVM: x86/mmu: Retry page faults that hit an invalid memslot Date: Wed, 12 May 2021 16:47:53 +0200 Message-Id: <20210512144840.852049991@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210512144827.811958675@linuxfoundation.org> References: <20210512144827.811958675@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Sean Christopherson [ Upstream commit e0c378684b6545ad2d4403bb701d0ac4932b4e95 ] Retry page faults (re-enter the guest) that hit an invalid memslot instead of treating the memslot as not existing, i.e. handling the page fault as an MMIO access. When deleting a memslot, SPTEs aren't zapped and the TLBs aren't flushed until after the memslot has been marked invalid. Handling the invalid slot as MMIO means there's a small window where a page fault could replace a valid SPTE with an MMIO SPTE. The legacy MMU handles such a scenario cleanly, but the TDP MMU assumes such behavior is impossible (see the BUG() in __handle_changed_spte()). There's really no good reason why the legacy MMU should allow such a scenario, and closing this hole allows for additional cleanups. Fixes: 2f2fad0897cb ("kvm: x86/mmu: Add functions to handle changed TDP SPTEs") Cc: Ben Gardon Signed-off-by: Sean Christopherson Message-Id: <20210225204749.1512652-6-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin --- arch/x86/kvm/mmu/mmu.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 3d5e4fdbf5fd..9dabd689a812 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -3676,6 +3676,14 @@ static bool try_async_pf(struct kvm_vcpu *vcpu, bool prefault, gfn_t gfn, struct kvm_memory_slot *slot = kvm_vcpu_gfn_to_memslot(vcpu, gfn); bool async; + /* + * Retry the page fault if the gfn hit a memslot that is being deleted + * or moved. This ensures any existing SPTEs for the old memslot will + * be zapped before KVM inserts a new MMIO SPTE for the gfn. + */ + if (slot && (slot->flags & KVM_MEMSLOT_INVALID)) + return true; + /* Don't expose private memslots to L2. */ if (is_guest_mode(vcpu) && !kvm_is_visible_memslot(slot)) { *pfn = KVM_PFN_NOSLOT; -- 2.30.2