From nobody Wed Nov 27 12:26:05 2024 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) (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 88E73191F82 for ; Wed, 9 Oct 2024 19:23:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728501832; cv=none; b=YK/0oGH+OLzybloQckUuvUkqfzs7hfzakpuWrxAky0C6TrxBplOZzXWD5I0RY9+ZGe/LO6+4Q1HL5YQIMRAPPBralgVMaStmaU3J/60fQBHi9ddNzteqAoJdh1mXsVcUtrslNtpG6hEWxSk8Oti3eTzySN0u3k50wwTJDdWEGUs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728501832; c=relaxed/simple; bh=imXtokP7LX0TTfuTLrfZD8ejaZvPA9bFhC2i8zqCO/o=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Z1SPJSgqFNYMhzvC9eJAhtEjYNjHre14ipSLNLyqRjtdP5i97A9WM6XlqqQGX/E4+PEzRtf3eL7U4yJhjAdiVTHOAeS/qw1ohAfBAwq2/3NtaqwR76VlEx/njQylLKWEb46O9BVWc/jK6wb+VzqQuRTszbwIS/Ns76C8L6qkUa4= 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=lJd24jf2; arc=none smtp.client-ip=209.85.216.74 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="lJd24jf2" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-2e2840c3a43so231387a91.1 for ; Wed, 09 Oct 2024 12:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1728501830; x=1729106630; 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=SoLsPzJZiQfoNHdfok3jrkhtn52skZ1suvpgub7z+jA=; b=lJd24jf24INjaMVP26V0yM4ib1gX0McrV4PDOA4548PlfmaOGtBlgQzKBvl0zHo5pZ rgVzWjqC/MbxbSvmD9FBQeSieJE+rjuFfsd6021F/Zgn2aCcMU0Fj3ygrTgb3l2/r9qZ Cb+7TZlvvdX1CTINX9J7nzWl73CVj6/Xi+d2MQJ325WrTfY/k7cpqoAOKbVgIxiYEIRy 0EpYm3I8wOmAm5WKIfz0f/pxQNuRd+jxTUae+M8V3ofaiU5JSJz79bqR+JY4b7VWAeFK qRVxnFDQQsitFDkzr8jn3MeiMPS3oDgNB4cfyGrEwbOcV22U++GTrxJRu2lZOck6p/sI DWBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728501830; x=1729106630; 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=SoLsPzJZiQfoNHdfok3jrkhtn52skZ1suvpgub7z+jA=; b=ufJ9LarQrkWAGHvR3ooF/f9vTaySnosJ0sWcW5trkc6GBa53esrZ1x+TipL3Z0L6ky YtvTE7u8QikpGgB0mFd2joV9Oz+E3VnFJW6RAv9z/t+70J8gzJ9q1c8A3ajLgwJcMpb/ w/xZGbjpNSgbM8wEutky1D6n06JXSOHQ8z49+QleUL2vsrjQwkcUaukCrwE4SkBsSEDP dY1yv5xWedMCBZ39/2ytal3QIFhwCN5jVH9aepXHKMMyxX3EmxSAoCqTKrDD3Rbo74ML CDVFffiwUBE9VWvKAg9V7k8oXMpJKkrbCk5WAd796ezFxzKzZuQ9wIEYb9sixgBOloYo UBSQ== X-Forwarded-Encrypted: i=1; AJvYcCUv7svik9FCGT9cONqgbma4tT7mwxdftdP/ACs7wtzmPMoVLCcegqZDzaWIsBhZ5U/FJZFSVCmFiFntDcI=@vger.kernel.org X-Gm-Message-State: AOJu0YztIjSC7Mmj57UtX9VPAHwgRz97iyNTpe2NQoELvusHYzOu7B+W vBd7IID9M8YM1IS16spBPJdoabFnLeaalDR503FXUNsUlQ627S943a8MVo+cKqnW7ECbVA8PBHm IcA== X-Google-Smtp-Source: AGHT+IGLBnTXpLPgqKd8QtJogAC2lHie+sZQ2T4w8hdKUFlyw02+Np52KEI5BR6vwpF7PUUtSnLjOGP9Mac= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:9d:3983:ac13:c240]) (user=seanjc job=sendgmr) by 2002:a17:90b:1b42:b0:2e0:b741:cdbc with SMTP id 98e67ed59e1d1-2e2a250791emr3715a91.4.1728501829578; Wed, 09 Oct 2024 12:23:49 -0700 (PDT) Reply-To: Sean Christopherson Date: Wed, 9 Oct 2024 12:23:43 -0700 In-Reply-To: <20241009192345.1148353-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: <20241009192345.1148353-1-seanjc@google.com> X-Mailer: git-send-email 2.47.0.rc1.288.g06298d1525-goog Message-ID: <20241009192345.1148353-2-seanjc@google.com> Subject: [PATCH 1/3] KVM: x86/mmu: Zap only SPs that shadow gPTEs when deleting memslot From: Sean Christopherson To: Paolo Bonzini , Sean Christopherson Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Yan Zhao Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When performing a targeted zap on memslot removal, zap only MMU pages that shadow guest PTEs, as zapping all SPs that "match" the gfn is inexact and unnecessary. Furthermore, for_each_gfn_valid_sp() arguably shouldn't exist, because it doesn't do what most people would it expect it to do. The "round gfn for level" adjustment that is done for direct SPs (no gPTE) means that the exact gfn comparison will not get a match, even when a SP does "cover" a gfn, or was even created specifically for a gfn. For memslot deletion specifically, KVM's behavior will vary significantly based on the size and alignment of a memslot, and in weird ways. E.g. for a 4KiB memslot, KVM will zap more SPs if the slot is 1GiB aligned than if it's only 4KiB aligned. And as described below, zapping SPs in the aligned case overzaps for direct MMUs, as odds are good the upper-level SPs are serving other memslots. To iterate over all potentially-relevant gfns, KVM would need to make a pass over the hash table for each level, with the gfn used for lookup rounded for said level. And then check that the SP is of the correct level, too, e.g. to avoid over-zapping. But even then, KVM would massively overzap, as processing every level is all but guaranteed to zap SPs that serve other memslots, especially if the memslot being removed is relatively small. KVM could mitigate that issue by processing only levels that can be possible guest huge pages, i.e. are less likely to be re-used for other memslot, but while somewhat logical, that's quite arbitrary and would be a bit of a mess to implement. So, zap only SPs with gPTEs, as the resulting behavior is easy to describe, is predictable, and is explicitly minimal, i.e. KVM only zaps SPs that absolutely must be zapped. Cc: Yan Zhao Signed-off-by: Sean Christopherson Reviewed-by: Yan Zhao Tested-by: Yan Zhao --- arch/x86/kvm/mmu/mmu.c | 16 ++++++---------- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index a9a23e058555..09494d01c38e 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -1884,14 +1884,10 @@ static bool sp_has_gptes(struct kvm_mmu_page *sp) if (is_obsolete_sp((_kvm), (_sp))) { \ } else =20 -#define for_each_gfn_valid_sp(_kvm, _sp, _gfn) \ +#define for_each_gfn_valid_sp_with_gptes(_kvm, _sp, _gfn) \ for_each_valid_sp(_kvm, _sp, \ &(_kvm)->arch.mmu_page_hash[kvm_page_table_hashfn(_gfn)]) \ - if ((_sp)->gfn !=3D (_gfn)) {} else - -#define for_each_gfn_valid_sp_with_gptes(_kvm, _sp, _gfn) \ - for_each_gfn_valid_sp(_kvm, _sp, _gfn) \ - if (!sp_has_gptes(_sp)) {} else + if ((_sp)->gfn !=3D (_gfn) || !sp_has_gptes(_sp)) {} else =20 static bool kvm_sync_page_check(struct kvm_vcpu *vcpu, struct kvm_mmu_page= *sp) { @@ -7063,15 +7059,15 @@ static void kvm_mmu_zap_memslot_pages_and_flush(str= uct kvm *kvm, =20 /* * Since accounting information is stored in struct kvm_arch_memory_slot, - * shadow pages deletion (e.g. unaccount_shadowed()) requires that all - * gfns with a shadow page have a corresponding memslot. Do so before - * the memslot goes away. + * all MMU pages that are shadowing guest PTEs must be zapped before the + * memslot is deleted, as freeing such pages after the memslot is freed + * will result in use-after-free, e.g. in unaccount_shadowed(). */ for (i =3D 0; i < slot->npages; i++) { struct kvm_mmu_page *sp; gfn_t gfn =3D slot->base_gfn + i; =20 - for_each_gfn_valid_sp(kvm, sp, gfn) + for_each_gfn_valid_sp_with_gptes(kvm, sp, gfn) kvm_mmu_prepare_zap_page(kvm, sp, &invalid_list); =20 if (need_resched() || rwlock_needbreak(&kvm->mmu_lock)) { --=20 2.47.0.rc1.288.g06298d1525-goog From nobody Wed Nov 27 12:26:05 2024 Received: from mail-pg1-f201.google.com (mail-pg1-f201.google.com [209.85.215.201]) (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 7CD9B1E1A30 for ; Wed, 9 Oct 2024 19:23:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728501833; cv=none; b=VbsEYlIXH6XVqcv8QxSLnhf/9qXwAl0TFDQEhgKflexly+49ajMabrEtoEH48P9cyMx1/LJmOh00Jp6yRBuV4JJiEpw2XUQRi4eVt3AilzwPK5GBtyEwUpmYOWy3A53R3cMFuSG6KIsM+vmd1TVWOOnWTpFor0qdB48/lxJHl3I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728501833; c=relaxed/simple; bh=ck6e1+clLHvY37y71iwCVIslPuIUb7JPkmFmrD3a1sQ=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Nbc/2lak4L+mbSeH2cs+JmQDux4XHbhpgITNTBbKSojjIuU27jEz8Vl9bedGCzpkx3Dl/cyj4gujkl4TNsUAiaSMu0nTaYADEkucihvn96j/puzyQCPmY0b4YPZM2njpvvgbHg0RZBWzu/maxYZ2gs37XQvy8RblaMx19jQTtH0= 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=N92p/F66; arc=none smtp.client-ip=209.85.215.201 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="N92p/F66" Received: by mail-pg1-f201.google.com with SMTP id 41be03b00d2f7-7c6a9c1a9b8so81623a12.0 for ; Wed, 09 Oct 2024 12:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1728501832; x=1729106632; 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=fx7eMx6VVUuvVYcfbaCKh7/MSwGopnW89lun6HOpi5I=; b=N92p/F66PYk+rn224Up55qmHhy8Lw+Dig5dtGTJkeclaHSciaQ/gWGfqbu9lxqu8VA MSeaSZldHDfP5kG1DdiyQ+bPpYfb81IM7AGFUKwBUBhg+z2QVVnl/ayw94KhkGd8QTbY +sIO7sVeGhKGmIp/+NmIAYAHX9CzOHthqPFS261JZcfAGAWdENLWhwiDhSO0BEefbh+6 8e64i7WvtmJ5iPxtM+OLHCUrIQU0EmYRMAKamq+H+IICO8o4sqvfib/PtXyfZ7q0dmnj mWhPbfXpvKJRv3DWmMvOiwjHsKYEs7/79OEeioqrMcvH7GPKk3m73faiut9DgtMMCdT2 lZXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728501832; x=1729106632; 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=fx7eMx6VVUuvVYcfbaCKh7/MSwGopnW89lun6HOpi5I=; b=WAiBiCObhblE161vhbkFyWQnp49aW8wPQR5NEcJtQyxf3ZxQFu/AOxfkejlkuCCe1D zfxZi6EGIA68kIwn3qVqMIAnLXMtcpBD53HBfBIcKvnBy1slsrrpBK+JHd37/yGGPdms OKmezZlF+erSrnmMMFix/mowajgwm1zEpm3zvPOGDFTxfcIsOVcF57LVISFgmhuS4gSQ PQJqa3pExFze18Fm1FKwHxA94lTvJL7rmScl/gKM8sZm0cKbxOmhvQxNUz7jAj/r8L9Q +EBBRoDMrH8fwuW2qpNHTXehkwABG/Xbl2k+7HObYH2iGWE0QFTDuaLcl4qv38tChzHi NcIg== X-Forwarded-Encrypted: i=1; AJvYcCVR8FBamwIc5EsFiFU+81FmAwNKOpWJBkNtAWeER03der11NL7dvK9O0E6M2oqWbnD1MRl+Kt8KjdfW+O8=@vger.kernel.org X-Gm-Message-State: AOJu0Yw0OwBG5o2WNZoN7aEoDNguB6YyWkUgWfkuw6rUyEs0H8jeOCbK txoIGNRgocFBRicDqQNidenQJzTP/IQHps2tEEtnEd1LU3OD3kat0Iz/vHjnX+BXfgfky7/XejT 8pQ== X-Google-Smtp-Source: AGHT+IFK05VgrJ7xkHvKexCmcT/byWx7dnDBJFxQBRnl03+WtCAsj2ptxNvLmZkLLNUb1oQXRFWnt4p+I5g= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:9d:3983:ac13:c240]) (user=seanjc job=sendgmr) by 2002:a63:6247:0:b0:7d5:e48:4286 with SMTP id 41be03b00d2f7-7ea320e1a64mr3014a12.7.1728501831481; Wed, 09 Oct 2024 12:23:51 -0700 (PDT) Reply-To: Sean Christopherson Date: Wed, 9 Oct 2024 12:23:44 -0700 In-Reply-To: <20241009192345.1148353-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: <20241009192345.1148353-1-seanjc@google.com> X-Mailer: git-send-email 2.47.0.rc1.288.g06298d1525-goog Message-ID: <20241009192345.1148353-3-seanjc@google.com> Subject: [PATCH 2/3] KVM: x86/mmu: Add lockdep assert to enforce safe usage of kvm_unmap_gfn_range() From: Sean Christopherson To: Paolo Bonzini , Sean Christopherson Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Yan Zhao Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Add a lockdep assertion in kvm_unmap_gfn_range() to ensure that either mmu_invalidate_in_progress is elevated, or that the range is being zapped due to memslot removal (loosely detected by slots_lock being held). Zapping SPTEs without mmu_invalidate_{in_progress,seq} protection is unsafe as KVM's page fault path snapshots state before acquiring mmu_lock, and thus can create SPTEs with stale information if vCPUs aren't forced to retry faults (due to seeing an in-progress or past MMU invalidation). Memslot removal is a special case, as the memslot is retrieved outside of mmu_invalidate_seq, i.e. doesn't use the "standard" protections, and instead relies on SRCU synchronization to ensure any in-flight page faults are fully resolved before zapping SPTEs. Signed-off-by: Sean Christopherson --- arch/x86/kvm/mmu/mmu.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 09494d01c38e..c6716fd3666f 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -1556,6 +1556,16 @@ bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm= _gfn_range *range) { bool flush =3D false; =20 + /* + * To prevent races with vCPUs faulting in a gfn using stale data, + * zapping a gfn range must be protected by mmu_invalidate_in_progress + * (and mmu_invalidate_seq). The only exception is memslot deletion, + * in which case SRCU synchronization ensures SPTEs a zapped after all + * vCPUs have unlocked SRCU and are guaranteed to see the invalid slot. + */ + lockdep_assert_once(kvm->mmu_invalidate_in_progress || + lockdep_is_held(&kvm->slots_lock)); + if (kvm_memslots_have_rmaps(kvm)) flush =3D __kvm_rmap_zap_gfn_range(kvm, range->slot, range->start, range->end, --=20 2.47.0.rc1.288.g06298d1525-goog From nobody Wed Nov 27 12:26:05 2024 Received: from mail-pg1-f202.google.com (mail-pg1-f202.google.com [209.85.215.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 6E3D11E22F9 for ; Wed, 9 Oct 2024 19:23:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.202 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728501835; cv=none; b=ZamUgT8dILWuUyD4ckDZgiOMfJFBWehvtojjoUIPzDO2D58OYEiY7bVrkz8YirtYlILFcRGOdr2EXZNIxHdsB81hDwbM//1Pe87m5CfmMS40hhlVeBQJzun7H23IKEbDhhyj+16Lg0KAeGsHsIZwBsB/qBuQPeNamRMsZV0ijXc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728501835; c=relaxed/simple; bh=i1AfRS5ndMXdqtCSQluoP1BVzX/y9mDGJV2x5I9dvrk=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=HUqrDleKxIP2lsJgoEAkn5//dr7u/h06EZrzAcAEOM4y7URrhDZZhxu4GBPmsW6B49AwaPj7iFm0RKt6JwehQ75qiMpT2Hk4cIfyNOgEEzpIsK+Qtyx8rbXLMBDozkEpYM5LwS/rwxXfY0VFB/cgJy62roW7KzvMmMIZ8hHCPM8= 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=DVYWPHMc; arc=none smtp.client-ip=209.85.215.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="DVYWPHMc" Received: by mail-pg1-f202.google.com with SMTP id 41be03b00d2f7-5e4df21f22dso213912a12.0 for ; Wed, 09 Oct 2024 12:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1728501834; x=1729106634; 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=i9BdalRrINJVrDcrtezLTinwXxj+SPewGxzSEbZM+70=; b=DVYWPHMcgr3JY2kq13sSYz2oBipEHg8tcrEXVGQKjdH0jizU7rp9g0/wbaRdyG/S2V 28fUE0aY8zZaBnKzfiyGwKNXaqWNGNCXLzSwvnUfMqYipBh0VnifuFBI9bkOKiqvDh49 rbKMXeUGI8YPq1kC4zGbZ+52ejP52V93IreckftUuDwWmMunYKYiBFydhgLjJusWXzv9 Prn3qo5VriiEkRS7xPdhQVM+Vwol9ZkpR6MZejDQYEvtqkfby1dBEX9cErPOledlRNT5 +kigCtEcJ5vZVWMc+R/j3L4EZWEpDlsxVcVp59C1gldC3P76PFw/x2Iv5X90VLOeCKAK 7snQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728501834; x=1729106634; 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=i9BdalRrINJVrDcrtezLTinwXxj+SPewGxzSEbZM+70=; b=ARu0CpUH61F8WuOPJqnSKWW89coOnrR9oDhJL0f1n1mhQil808hlSZoPH72pdYY2kn tH7yP/fp/f18fvQd2oi5uFO+F3BWFT7iuGqhTGD41jCs2h3G7T+wjHFUXzdWqcyGMRh2 Z+maIx3OL24KrTaPkMJxFdfFAKdQCutCg8IUMtUrm391xXGhfJ1/a9hCSik4xeWFZFk7 yK8g4106F1g7wJkPDvrAs//a/8TgpTtvILyUI8jJefa2ya3m88BqAwsl+Wae/k++Zbgn pwlVYdzHV+az5J3wbU4Vg6ov2Vkr6/FbjBoh/hTxusmK8tw76JFlCBHR38qvrxC24ZYR p/Qg== X-Forwarded-Encrypted: i=1; AJvYcCWkgk3bzBVaduagAcp60iJADp8keYjSDsAPZiA+vE5TPglywSLNzsWSWCrNVAImaqHo9NfjWnkpl2VEZz8=@vger.kernel.org X-Gm-Message-State: AOJu0YxqEWKA4BJlCuqrp2Ze+RqRTNnnezqfoTHAQOjIPaU1jRVMnSMG XS0BUQlkJBvf7DwfGETvmoXGQQNRTfkjGemo0MlhOWb7IOi+6r6L3Nu0rbPsABorNDQdFjZMcuI Hig== X-Google-Smtp-Source: AGHT+IGdx+V3bQgWDNAJK6Wy1vX01P4om5Fw6X1AQADID6XkrRPdfHX3uXvEWSRXRAwVh5niEzh7Nqh+YL4= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:9d:3983:ac13:c240]) (user=seanjc job=sendgmr) by 2002:a63:b208:0:b0:7a1:6a6b:4a5b with SMTP id 41be03b00d2f7-7ea3f892d1cmr649a12.2.1728501833564; Wed, 09 Oct 2024 12:23:53 -0700 (PDT) Reply-To: Sean Christopherson Date: Wed, 9 Oct 2024 12:23:45 -0700 In-Reply-To: <20241009192345.1148353-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: <20241009192345.1148353-1-seanjc@google.com> X-Mailer: git-send-email 2.47.0.rc1.288.g06298d1525-goog Message-ID: <20241009192345.1148353-4-seanjc@google.com> Subject: [PATCH 3/3] KVM: x86: Clean up documentation for KVM_X86_QUIRK_SLOT_ZAP_ALL From: Sean Christopherson To: Paolo Bonzini , Sean Christopherson Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Yan Zhao Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Massage the documentation for KVM_X86_QUIRK_SLOT_ZAP_ALL to call out that it applies to moved memslots as well as deleted memslots, to avoid KVM's "fast zap" terminology (which has no meaning for userspace), and to reword the documented targeted zap behavior to specifically say that KVM _may_ zap a subset of all SPTEs. As evidenced by the fix to zap non-leafs SPTEs with gPTEs, formally documenting KVM's exact internal behavior is risky and unnecessary. Signed-off-by: Sean Christopherson --- Documentation/virt/kvm/api.rst | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index e32471977d0a..edc070c6e19b 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -8098,13 +8098,15 @@ KVM_X86_QUIRK_MWAIT_NEVER_UD_FAULTS By default, KVM= emulates MONITOR/MWAIT (if KVM_X86_QUIRK_MISC_ENABLE_NO_MWAIT is disabled. =20 -KVM_X86_QUIRK_SLOT_ZAP_ALL By default, KVM invalidates all SPTEs = in - fast way for memslot deletion when VM = type - is KVM_X86_DEFAULT_VM. - When this quirk is disabled or when VM= type - is other than KVM_X86_DEFAULT_VM, KVM = zaps - only leaf SPTEs that are within the ra= nge of - the memslot being deleted. +KVM_X86_QUIRK_SLOT_ZAP_ALL By default, for KVM_X86_DEFAULT_VM VMs= , KVM + invalidates all SPTEs in all memslots = and + address spaces when a memslot is delet= ed or + moved. When this quirk is disabled (o= r the + VM type isn't KVM_X86_DEFAULT_VM), KVM= only + ensures the backing memory of the dele= ted + or moved memslot isn't reachable, i.e = KVM + _may_ invalidate only SPTEs related to= the + memslot. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D =20 7.32 KVM_CAP_MAX_VCPU_ID --=20 2.47.0.rc1.288.g06298d1525-goog