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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id 564F1C433F5 for ; Fri, 22 Apr 2022 20:41:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id B260549EB5; Fri, 22 Apr 2022 16:41:58 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@google.com Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 640hrQwgXbXQ; Fri, 22 Apr 2022 16:41:57 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id A41524A193; Fri, 22 Apr 2022 16:41:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id DF9FD49F06 for ; Fri, 22 Apr 2022 16:41:56 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kcNWgtSnYmA for ; Fri, 22 Apr 2022 16:41:56 -0400 (EDT) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id E7A3A49EB5 for ; Fri, 22 Apr 2022 16:41:55 -0400 (EDT) Received: by mail-io1-f47.google.com with SMTP id c125so9814445iof.9 for ; Fri, 22 Apr 2022 13:41:55 -0700 (PDT) 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=PIHedjvBDUsd4o0hzUsuDNj6ptFVTAlpQe59DURQa44=; b=oPO5Yme2y6EXk+fi6Lg8OhVIAVnIWkQGaDDC9BX04q6vbLeGn9fa4C+0nNAI1KB3Ap GJ3lDkeLxz/RC2Mn+I0BJbJ/SIcCy3bkUVoidHCqveVWxNpOniChJSHEjoXOUv3v3hEK ttEB6l7t9bxij3rfjOiWbcpjsBWLHC8NYvFw48qjT/lcQV79kYwH7HvuHrqnzfqm2VhL jmbhjaqlWtqQLTXWVnSmIL7dtVKNqaQgoLSPeES5HDckhkWXKBxiE3YsewOYkDwjCvdc wRZSzh0E0v/26h84z5+gDanAse3uW30/Q8TyYTi046k7NDB4ay0Wi/dpb949ukm52o+K ZEMQ== 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=PIHedjvBDUsd4o0hzUsuDNj6ptFVTAlpQe59DURQa44=; b=g68z3Dy/h8QCegjAIRm0wT51Sq7ZtpUgO5m/Klo3tF3y2924XVUP1XWVlyDRKzVvp5 yGVQ/SCVUofy0Qo0HOgxc3q6SnF0mZuJaXHPkYUntahWLxpVBn+ICUykEmTdbKEU2piV PfQNKUajg+7RCk9gtOTkSoAlqKSYC2/k1XS6E0tB7t0U2pPCl0G/2GS/CH+oaWTq565E bx3AmE/DankSs8n7MnP7iVsRJvsYpw2A6qnqmZBUdVC8s7+OjF1Fa7t3+tY59efdfEG/ qj81nFR3ha7lk7FHVcOrX5wNnMzK00BfZi7IhMBA1Xf8E2qZhDTemoIYIkIf6ICS7ULF S++g== X-Gm-Message-State: AOAM533sA2S03PKQCI/b0bXiJ1hyKr2k5gHaBOwJotNsvfnQJoNYt0A8 Iov9fsMAXDioJveF3ziqGqJhNw== X-Google-Smtp-Source: ABdhPJy+APL9BkWInbd+QFDrmKyPHiSNDP9EVCz9Mw0NDYDizkUIV8IR5t71M6VANKddfh1vSizGaA== X-Received: by 2002:a05:6638:35a0:b0:32a:8f99:fa03 with SMTP id v32-20020a05663835a000b0032a8f99fa03mr3002986jal.8.1650660115087; Fri, 22 Apr 2022 13:41:55 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id w3-20020a92d2c3000000b002cbca0cd15fsm1970376ilg.8.2022.04.22.13.41.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Apr 2022 13:41:53 -0700 (PDT) Date: Fri, 22 Apr 2022 20:41:47 +0000 From: Oliver Upton To: Quentin Perret Subject: Re: [RFC PATCH 09/17] KVM: arm64: Tear down unlinked page tables in parallel walk Message-ID: References: <20220415215901.1737897-1-oupton@google.com> <20220415215901.1737897-10-oupton@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: kvm@vger.kernel.org, Marc Zyngier , Peter Shier , Ben Gardon , David Matlack , Paolo Bonzini , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Fri, Apr 22, 2022 at 04:00:45PM +0000, Quentin Perret wrote: > On Thursday 21 Apr 2022 at 16:40:56 (+0000), Oliver Upton wrote: > > The other option would be to not touch the subtree at all until the rcu > > callback, as at that point software will not tweak the tables any more. > > No need for atomics/spinning and can just do a boring traversal. > > Right that is sort of what I had in mind. Note that I'm still trying to > make my mind about the overall approach -- I can see how RCU protection > provides a rather elegant solution to this problem, but this makes the > whole thing inaccessible to e.g. pKVM where RCU is a non-starter. Heh, figuring out how to do this for pKVM seemed hard hence my lazy attempt :) > A > possible alternative that comes to mind would be to have all walkers > take references on the pages as they walk down, and release them on > their way back, but I'm still not sure how to make this race-safe. I'll > have a think ... Does pKVM ever collapse tables into blocks? That is the only reason any of this mess ever gets roped in. If not I think it is possible to get away with a rwlock with unmap on the write side and everything else on the read side, right? As far as regular KVM goes we get in this business when disabling dirty logging on a memslot. Guest faults will lazily collapse the tables back into blocks. An equally valid implementation would be just to unmap the whole memslot and have the guest build out the tables again, which could work with the aforementioned rwlock. Do any of my ramblings sound workable? :) -- Thanks, Oliver _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0D2EDC433F5 for ; Fri, 22 Apr 2022 20:43:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=oitg6o/CkScmh6B+SXe807A32Z0BUiGfmSr+1dN73yQ=; b=fkE0DD5qw35Wn9 2qVKsfHs3NG+UuyeNjGCTLJzoqDVLVtSJ3cIJ9JFlwK1QAYaDk/5mP9wMacejflZfLQovMa8hVyUD Bm3vreUevYBbPG4rYG8smbkalj3iE+jyKA9TqXSJJFSJc+S/AvvZZu4ylZfngIRP70uegDDj7VrLj yJfHKjjz6uxMNF///6csS1EtWf9Vog9nVfcglIy5wSI1jLBEI5ATxSZXfeltf+ycod/IcSlztecqj j+JwhLxNwclvRmfITxK7nMMTISjWsYuyrts4SK2hzbczvf+wYRdob/A37334iYeVz/La8m9SP1w2B GHMHxNfTpUR4A3ZU7vCw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ni06N-002Gtb-JO; Fri, 22 Apr 2022 20:42:03 +0000 Received: from mail-io1-xd2a.google.com ([2607:f8b0:4864:20::d2a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ni06K-002Gt2-RT for linux-arm-kernel@lists.infradead.org; Fri, 22 Apr 2022 20:42:02 +0000 Received: by mail-io1-xd2a.google.com with SMTP id 79so9823552iou.7 for ; Fri, 22 Apr 2022 13:41:55 -0700 (PDT) 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=PIHedjvBDUsd4o0hzUsuDNj6ptFVTAlpQe59DURQa44=; b=oPO5Yme2y6EXk+fi6Lg8OhVIAVnIWkQGaDDC9BX04q6vbLeGn9fa4C+0nNAI1KB3Ap GJ3lDkeLxz/RC2Mn+I0BJbJ/SIcCy3bkUVoidHCqveVWxNpOniChJSHEjoXOUv3v3hEK ttEB6l7t9bxij3rfjOiWbcpjsBWLHC8NYvFw48qjT/lcQV79kYwH7HvuHrqnzfqm2VhL jmbhjaqlWtqQLTXWVnSmIL7dtVKNqaQgoLSPeES5HDckhkWXKBxiE3YsewOYkDwjCvdc wRZSzh0E0v/26h84z5+gDanAse3uW30/Q8TyYTi046k7NDB4ay0Wi/dpb949ukm52o+K ZEMQ== 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=PIHedjvBDUsd4o0hzUsuDNj6ptFVTAlpQe59DURQa44=; b=I48GsOxvLGPEkiz8qWRsJvAUv9xGg+5kYM1UJzu4KTSRBtvTq+okTVecxdbNetwZnY ZbLPVzXXBhvZLLXfCjwSofFoBxo82sJRNZLT74BBumxpKyZVyk8QWgCeKvJguSdL3z9U mb4GjmzIYUGBfi4X3SWueHCBXNJ7/k6VeZ1O4F+11mDVqMIpKU/MfzBUCT7Q3eYzt38V Z866gRUEl1aAXCR6rTFKPOUujlRDzd0AD4FcENZKf1BsNqyfymyh06oE2yvXm1h6whXE B0Z7jw7MoFeACj3RGTxPhn5cXPdwvILsY3desaUKvglqHlr0ODS+hdC/ezegDqk2skGJ 0FvQ== X-Gm-Message-State: AOAM531tQrSAIN1uCHxlopXOjxhSLe8pcIlRaxiFOK7+kcKZla4Gj43c hhsLLzeeeRLTnij83JFS3x+Crw== X-Google-Smtp-Source: ABdhPJy+APL9BkWInbd+QFDrmKyPHiSNDP9EVCz9Mw0NDYDizkUIV8IR5t71M6VANKddfh1vSizGaA== X-Received: by 2002:a05:6638:35a0:b0:32a:8f99:fa03 with SMTP id v32-20020a05663835a000b0032a8f99fa03mr3002986jal.8.1650660115087; Fri, 22 Apr 2022 13:41:55 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id w3-20020a92d2c3000000b002cbca0cd15fsm1970376ilg.8.2022.04.22.13.41.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Apr 2022 13:41:53 -0700 (PDT) Date: Fri, 22 Apr 2022 20:41:47 +0000 From: Oliver Upton To: Quentin Perret Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Marc Zyngier , Ben Gardon , Peter Shier , David Matlack , Paolo Bonzini , linux-arm-kernel@lists.infradead.org Subject: Re: [RFC PATCH 09/17] KVM: arm64: Tear down unlinked page tables in parallel walk Message-ID: References: <20220415215901.1737897-1-oupton@google.com> <20220415215901.1737897-10-oupton@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220422_134200_925508_6C9BB52C X-CRM114-Status: GOOD ( 21.97 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Apr 22, 2022 at 04:00:45PM +0000, Quentin Perret wrote: > On Thursday 21 Apr 2022 at 16:40:56 (+0000), Oliver Upton wrote: > > The other option would be to not touch the subtree at all until the rcu > > callback, as at that point software will not tweak the tables any more. > > No need for atomics/spinning and can just do a boring traversal. > > Right that is sort of what I had in mind. Note that I'm still trying to > make my mind about the overall approach -- I can see how RCU protection > provides a rather elegant solution to this problem, but this makes the > whole thing inaccessible to e.g. pKVM where RCU is a non-starter. Heh, figuring out how to do this for pKVM seemed hard hence my lazy attempt :) > A > possible alternative that comes to mind would be to have all walkers > take references on the pages as they walk down, and release them on > their way back, but I'm still not sure how to make this race-safe. I'll > have a think ... Does pKVM ever collapse tables into blocks? That is the only reason any of this mess ever gets roped in. If not I think it is possible to get away with a rwlock with unmap on the write side and everything else on the read side, right? As far as regular KVM goes we get in this business when disabling dirty logging on a memslot. Guest faults will lazily collapse the tables back into blocks. An equally valid implementation would be just to unmap the whole memslot and have the guest build out the tables again, which could work with the aforementioned rwlock. Do any of my ramblings sound workable? :) -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 8BD3CC433F5 for ; Fri, 22 Apr 2022 21:56:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230372AbiDVV7F (ORCPT ); Fri, 22 Apr 2022 17:59:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58942 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231159AbiDVV7A (ORCPT ); Fri, 22 Apr 2022 17:59:00 -0400 Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ADC762B6F70 for ; Fri, 22 Apr 2022 13:41:56 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id y85so9848314iof.3 for ; Fri, 22 Apr 2022 13:41:56 -0700 (PDT) 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=PIHedjvBDUsd4o0hzUsuDNj6ptFVTAlpQe59DURQa44=; b=oPO5Yme2y6EXk+fi6Lg8OhVIAVnIWkQGaDDC9BX04q6vbLeGn9fa4C+0nNAI1KB3Ap GJ3lDkeLxz/RC2Mn+I0BJbJ/SIcCy3bkUVoidHCqveVWxNpOniChJSHEjoXOUv3v3hEK ttEB6l7t9bxij3rfjOiWbcpjsBWLHC8NYvFw48qjT/lcQV79kYwH7HvuHrqnzfqm2VhL jmbhjaqlWtqQLTXWVnSmIL7dtVKNqaQgoLSPeES5HDckhkWXKBxiE3YsewOYkDwjCvdc wRZSzh0E0v/26h84z5+gDanAse3uW30/Q8TyYTi046k7NDB4ay0Wi/dpb949ukm52o+K ZEMQ== 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=PIHedjvBDUsd4o0hzUsuDNj6ptFVTAlpQe59DURQa44=; b=JtJr5RqJlpMk/W/iMBDOVQ0jbBCbtfhCyp7EwUtn9W8GO1c9Ap7GBz4fbspMuVX2c1 9QQEtZ7nGzOtMC/qQP08aagXj4hlJMdT+WdSwRmiqUzZG2wTpQKAWW7aFQMyfJBRFvZc qRoISmBbtCLgpuY8A/Uyo7wwRJjYH64oKDWZqzVXEAqHoH1VSp+Ax7NTJ7Stm+pV2Vli MYG7QZcCj7C8pm1Qp5/ocGwx1hafIigI0bngqPhcPLOBYgKs13kdA5/WdGJVKvu6blwp ZKq5D81A1RefxvUXg9jn+KErKrMLAqRX+rW2logc+0IEoc985w9is38YdLFoVeyoGGPD 4eAQ== X-Gm-Message-State: AOAM533w145WyugE5G6fJIsZcSapUbvnB7iKbFUHQBGJepWNgybR44uj 3s+BSXkWReHiL/Wh0p1f9znUcg== X-Google-Smtp-Source: ABdhPJy+APL9BkWInbd+QFDrmKyPHiSNDP9EVCz9Mw0NDYDizkUIV8IR5t71M6VANKddfh1vSizGaA== X-Received: by 2002:a05:6638:35a0:b0:32a:8f99:fa03 with SMTP id v32-20020a05663835a000b0032a8f99fa03mr3002986jal.8.1650660115087; Fri, 22 Apr 2022 13:41:55 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id w3-20020a92d2c3000000b002cbca0cd15fsm1970376ilg.8.2022.04.22.13.41.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Apr 2022 13:41:53 -0700 (PDT) Date: Fri, 22 Apr 2022 20:41:47 +0000 From: Oliver Upton To: Quentin Perret Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Marc Zyngier , Ben Gardon , Peter Shier , David Matlack , Paolo Bonzini , linux-arm-kernel@lists.infradead.org Subject: Re: [RFC PATCH 09/17] KVM: arm64: Tear down unlinked page tables in parallel walk Message-ID: References: <20220415215901.1737897-1-oupton@google.com> <20220415215901.1737897-10-oupton@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: kvm@vger.kernel.org On Fri, Apr 22, 2022 at 04:00:45PM +0000, Quentin Perret wrote: > On Thursday 21 Apr 2022 at 16:40:56 (+0000), Oliver Upton wrote: > > The other option would be to not touch the subtree at all until the rcu > > callback, as at that point software will not tweak the tables any more. > > No need for atomics/spinning and can just do a boring traversal. > > Right that is sort of what I had in mind. Note that I'm still trying to > make my mind about the overall approach -- I can see how RCU protection > provides a rather elegant solution to this problem, but this makes the > whole thing inaccessible to e.g. pKVM where RCU is a non-starter. Heh, figuring out how to do this for pKVM seemed hard hence my lazy attempt :) > A > possible alternative that comes to mind would be to have all walkers > take references on the pages as they walk down, and release them on > their way back, but I'm still not sure how to make this race-safe. I'll > have a think ... Does pKVM ever collapse tables into blocks? That is the only reason any of this mess ever gets roped in. If not I think it is possible to get away with a rwlock with unmap on the write side and everything else on the read side, right? As far as regular KVM goes we get in this business when disabling dirty logging on a memslot. Guest faults will lazily collapse the tables back into blocks. An equally valid implementation would be just to unmap the whole memslot and have the guest build out the tables again, which could work with the aforementioned rwlock. Do any of my ramblings sound workable? :) -- Thanks, Oliver