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 3854CC433F5 for ; Thu, 3 Mar 2022 23:07:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232660AbiCCXHx (ORCPT ); Thu, 3 Mar 2022 18:07:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59554 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230199AbiCCXHv (ORCPT ); Thu, 3 Mar 2022 18:07:51 -0500 Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E369E12AE8 for ; Thu, 3 Mar 2022 15:07:03 -0800 (PST) Received: by mail-pj1-x1033.google.com with SMTP id v4so5921204pjh.2 for ; Thu, 03 Mar 2022 15:07:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=wsytA5en+ItUqruLb4F/YGyRxRL/LbEBBpbjnswyCM8=; b=EOrYv2zrhk9TWezM970VEXgU/SbfP82z4FbUmK+LjtSUU9pY+C+Wk+f/zBqYlSXA/a Ww4tMAL8LjMgy1f4nmU4kUSwmRL019Y4izs5Fmy/y53ymi/qopXdHs+h1vUSXv8omro2 ieXiH/PlD215WhzH562QpXM8rNA40+XvObuhuAxeOpwsw73HDBcE1idHi3mvm4pJcOD5 2Fw3IY0MLMmMTG7SbfX4bqXvYSQpSAUE58VlDRA3N4wZvixHXZ7ZwNU77D9PUjr7j5CA uhB0ioX7fVTwQix49pvqHEGzC9JZt99Sz6mPcTUxSwWN2xM6KcIq9TiVWC8s+Ko25WyL 4zBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=wsytA5en+ItUqruLb4F/YGyRxRL/LbEBBpbjnswyCM8=; b=aJBzBvRbAhKAPCE5cHpo1inGFJqm6uPIcbUs0s9LRQkokjkk+514xTHolC7e1KDotX eTWLAhU+0OwNIQOqxcAP1AIIKJY3zZqGlU09eipakr0UFZ9cXVspEJ1Pn9KhlYInatU5 vn83jcknfkedV65ugci9l3JqiazDdx879yVMAdYS6In6WqOAW+nx+m+p+XFlnC/xKAhJ FNpQZqnMrVO05GDUu8PlJ3haJtmM+NQqkdlixOUEzPzixatpPuL0xcZ7KDh9M+If5ZXI rnW6wAlF/pJKwXNuN+YLo4A+NYu7nTNW/F/MebwCfPKuQXgy+zrmc1qv+3ACqBXia7Qf 2YXA== X-Gm-Message-State: AOAM532RX8cqvtf3OYrkfRD1cpm9KxNIpHts6rg83S6mZC+9eO93jxWS T3qgzctjcnoz9cjHy3MQMjddTw== X-Google-Smtp-Source: ABdhPJwo9c8LbCkavdKfpoadHPuUcYrp0SSG4dnjNHU5gp2pCtsaa3ksUhu2md7xyaz1S92gcf2Hxw== X-Received: by 2002:a17:903:41d0:b0:151:8b0c:5dd1 with SMTP id u16-20020a17090341d000b001518b0c5dd1mr14207833ple.160.1646348822205; Thu, 03 Mar 2022 15:07:02 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id m20-20020a634c54000000b003739af127c9sm2942153pgl.70.2022.03.03.15.07.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Mar 2022 15:07:01 -0800 (PST) Date: Thu, 3 Mar 2022 23:06:57 +0000 From: Sean Christopherson To: Mingwei Zhang Cc: Paolo Bonzini , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , David Hildenbrand , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, David Matlack , Ben Gardon Subject: Re: [PATCH v3 15/28] KVM: x86/mmu: Add dedicated helper to zap TDP MMU root shadow page Message-ID: References: <20220226001546.360188-1-seanjc@google.com> <20220226001546.360188-16-seanjc@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 03, 2022, Mingwei Zhang wrote: > On Thu, Mar 03, 2022, Mingwei Zhang wrote: > > > + /* > > > + * No need to try to step down in the iterator when zapping an entire > > > + * root, zapping an upper-level SPTE will recurse on its children. > > > + */ > > > + for_each_tdp_pte_min_level(iter, root, root->role.level, start, end) { > > > +retry: > > > + /* > > > + * Yielding isn't allowed when zapping an unreachable root as > > > + * the root won't be processed by mmu_notifier callbacks. When > > > + * handling an unmap/release mmu_notifier command, KVM must > > > + * drop all references to relevant pages prior to completing > > > + * the callback. Dropping mmu_lock can result in zapping SPTEs > > > + * for an unreachable root after a relevant callback completes, > > > + * which leads to use-after-free as zapping a SPTE triggers > > > + * "writeback" of dirty/accessed bits to the SPTE's associated > > > + * struct page. > > > + */ > > > > I have a quick question here: when the roots are unreachable, we can't > > yield, understand that after reading the comments. However, what if > > there are too many SPTEs that need to be zapped that requires yielding. > > In this case, I guess we will have a RCU warning, which is unavoidable, > > right? > > I will take that back. I think the subsequent patches solve the problem > using two passes. Yes, but it's worth noting that the yielding problem is also solved by keeping roots reachable while they're being zapped (also done in later patches). That way if a mmu_notifier event comes along, it can guarantee the SPTEs it cares about are zapped (and their metadata flushed) even if the MMU root is no longer usable by a vCPU.