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 631A0E732FD for ; Thu, 28 Sep 2023 18:11:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232113AbjI1SLa (ORCPT ); Thu, 28 Sep 2023 14:11:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52618 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231958AbjI1SL2 (ORCPT ); Thu, 28 Sep 2023 14:11:28 -0400 Received: from mail-pl1-x64a.google.com (mail-pl1-x64a.google.com [IPv6:2607:f8b0:4864:20::64a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 568D21AE for ; Thu, 28 Sep 2023 11:11:26 -0700 (PDT) Received: by mail-pl1-x64a.google.com with SMTP id d9443c01a7336-1c73637061eso11041545ad.3 for ; Thu, 28 Sep 2023 11:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695924686; x=1696529486; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=3K3OcXUIZlyHiQujf4H1r+veO7DYVI9kt+g/p8aiVWg=; b=nPqAySzjXtovxpRtzSERHIs/5NPmEyF6CzwLhYIMoQ/GgojvijSn8Sz2dJIrOP3HZg 4yLOhyTQwAOoILTMt1WuKPFfXxGIQvriwCIwSTw8gw4RON+smGw3BLdBVMq1tLIeeEc9 uT4Cvm4davSBDuYWl9pcejUdYP/d3pNjyp1bDEzT8zBkvoZ6PWHXqYf9DQ8MD/VEr3nv YbOQuRRL1I2CcbeA4/jno14MlAUJbvhi/qNmUwWKG7hco6MkHejz2tdAOjxL4XYA7Sv7 LtiJqgOKV6G4Q/VlUNtxoVTihIP6ElO3cW9mpOQOfbi09nEZLtbgFyybuDQqowXKKO56 GT3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695924686; x=1696529486; h=content-transfer-encoding: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=3K3OcXUIZlyHiQujf4H1r+veO7DYVI9kt+g/p8aiVWg=; b=D9/sdFzzPDR7piIn7qVyj1NmdGoMhe+iOX+qnRhCPGQ63JlZlcb0QuOZp1V10NjzjZ J44sL2SyEv7DdE8UtRHBw6KdD6l5COFtqgzyljtHyBGFK5D7nfpcJNQK3vfX6ZrjvMBI x9GijyZBeJn+hViUgbCiGqtWppjFdou65O1C5yoRJUUPsaCIg+h9Sbwn2ss8hUPV8KTt QlQbb+glAK/P0aFOyWoDrwknao02+QTraZSKogtC37uV3aZVmV3kXZtsoOkP5CusgC7J sW2yHZYQfYFiEPSfImaV9yNXJ3kcotAgyv/L9JhxdUkTidg5xz3RxKzF1qbxJNsRT4CM s+AQ== X-Gm-Message-State: AOJu0YxV6Gk5x4n7s+E+SU1eqNF398xOar7JMEbQD3J2xB6qc1Psmtj+ bxmtHy1xVDVwpNdq2WJcXFaO+YsveVQ= X-Google-Smtp-Source: AGHT+IG/xeSKSWDrjUnSnauQhpFmESuw5TvE/OCLZlz0n2YcWK5OqQSKvR8fdO5LRdL28kr6xQ6xAMA1ruQ= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:903:32cf:b0:1c6:1e4e:b78f with SMTP id i15-20020a17090332cf00b001c61e4eb78fmr26726plr.6.1695924685737; Thu, 28 Sep 2023 11:11:25 -0700 (PDT) Date: Thu, 28 Sep 2023 11:11:24 -0700 In-Reply-To: <7be47fe7-9587-dd1b-fac1-5c4d5c6e2ff6@linux.intel.com> Mime-Version: 1.0 References: <20230921203331.3746712-1-seanjc@google.com> <20230921203331.3746712-5-seanjc@google.com> <7be47fe7-9587-dd1b-fac1-5c4d5c6e2ff6@linux.intel.com> Message-ID: Subject: Re: [PATCH 04/13] KVM: WARN if there are danging MMU invalidations at VM destruction From: Sean Christopherson To: Binbin Wu Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Paolo Bonzini , Michael Roth Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 27, 2023, Binbin Wu wrote: >=20 >=20 > On 9/22/2023 4:33 AM, Sean Christopherson wrote: > > Add an assertion that there are no in-progress MMU invalidations when a > > VM is being destroyed, with the exception of the scenario where KVM > > unregisters its MMU notifier between an .invalidate_range_start() call = and > > the corresponding .invalidate_range_end(). > >=20 > > KVM can't detect unpaired calls from the mmu_notifier due to the above > > exception waiver, but the assertion can detect KVM bugs, e.g. such as t= he > > bug that *almost* escaped initial guest_memfd development. > >=20 > > Link: https://lore.kernel.org/all/e397d30c-c6af-e68f-d18e-b4e3739c5389@= linux.intel.com > > Signed-off-by: Sean Christopherson > > --- > > virt/kvm/kvm_main.c | 9 ++++++++- > > 1 file changed, 8 insertions(+), 1 deletion(-) > >=20 > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > > index 54480655bcce..277afeedd670 100644 > > --- a/virt/kvm/kvm_main.c > > +++ b/virt/kvm/kvm_main.c > > @@ -1381,9 +1381,16 @@ static void kvm_destroy_vm(struct kvm *kvm) > > * No threads can be waiting in kvm_swap_active_memslots() as the > > * last reference on KVM has been dropped, but freeing > > * memslots would deadlock without this manual intervention. > > + * > > + * If the count isn't unbalanced, i.e. KVM did NOT unregister between > Nit: Readers can get it according to the code context, but is it better t= o > add "MMU notifier"=C2=A0 to tell what to "unregister" to make the comment= easier > to understand? Agreed, I'll add that when applying.