From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) (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 A08C62F29 for ; Wed, 29 Jan 2025 08:12:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738138377; cv=none; b=BJPPqJnAZtYgoNMdBBgwyPc5C+haVsszaKASRCj2xAUI5fFKy4KZXxTm+UviuDrudkw02UMp0Dkr80BBq+TVTiOi/EttkPlrnmrSslVZi8YrPEjQsAGd0Rt98VJsiF0ite0VLOMTbnZ+PlvhdZDTaldkfB5vsBsb8amCJS/w7H0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738138377; c=relaxed/simple; bh=6VoW6SWCAQYhTTTQFlv9NqrWMcKguFt7ynWT5tPds+0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gnbCNidua1kTfbOB2nRG5XvbfUUx3/52xOp3IwVhgt5dxReaxJu1+/dPX5ExlnbPFYywN0Hp+e8+j7Y7Cq8ksT5BiomcigXQ7weK3phRzYcQgChO4PYWJ8FCaZr7TPgnyHmpTdlS9b2WEYPyX6zAnXCq1O6uNY0/7CdlBzaxIUQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com; spf=pass smtp.mailfrom=rivosinc.com; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b=Tf5g2eq1; arc=none smtp.client-ip=209.85.214.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b="Tf5g2eq1" Received: by mail-pl1-f178.google.com with SMTP id d9443c01a7336-2167141dfa1so7792495ad.1 for ; Wed, 29 Jan 2025 00:12:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1738138374; x=1738743174; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=lONUrJ6bY6rW44DopvDuoOtVc+vwMWPYLl3whw4FG6A=; b=Tf5g2eq1/+3Vvz8KmtGhdfcfbgertpv3/9ZuNSVJrCpOOhCS8DdigxVUrLcToD5qtz l71Qqg3VYaq4mjFnwao6KCIpsvy7TTeuo+jIb//EKhuM4lRf/DnXcexvddM8NGvkyQSL 67b1yOV3SF0FHZnuI1N2M4rUs6hVCIFGFd6CUpp4mUgdIgSuXXq7m+hKMARSEOZ5Yius mw8Wt6gMlxG1n71RLqDdUqQcCKog9WM0S47WTWmfvBfSXvwOCG4CCQY771rCsh47qZP4 L3TNOtzNyZ4r2AIIBR3xn9xSCg3ReGrLPTyTyTj2NxMfIXRNnfHg2umt7DEMRvCGBAA/ 94Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738138374; x=1738743174; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=lONUrJ6bY6rW44DopvDuoOtVc+vwMWPYLl3whw4FG6A=; b=eOcSYx8JXiTci0LDZdUQYo3yQeVyoz9Us7S50PlnFX554rfs3haaYYo7tF1j8qVUwE gwGkaWFqr7WrbfaXsoVbvMClpzcO2hjAbSQcST/Uxurajl+uWd6GMgvTpoTL2F+YGZhE uVo+ghX2L7GhwwOBU76LyLdkANnqsD8CCKKBWM9u+gpjyMe8+7WXjXxSC8nmbnge2l1E mPdBD8KrZTaUwWmu+UONRp6/RN8rCijQjjG6T6jmaHOt6Y4pCJhvUawGWISRqHneNtV7 6DgcXVouQ9Ny7onI+7XE0lvJWWfc3ZpPVejDac+AZLZWwg2jk3ZwIkvVzv2jQFkXlDmb A7qg== X-Forwarded-Encrypted: i=1; AJvYcCUhha9IBzxii59LVPaqDOVvHvPi2BfYyDIYUW2zn2EGTeeunAVoNDq+nhIdgl0N01ntgYziSFioSjv+vFI=@vger.kernel.org X-Gm-Message-State: AOJu0YyqTTsTAbIRdAXS88X68LOJ/EzoixQOW3O808nl5dxHCV//dVsy 199Oo78BXhw4ngRnMDylQreOad9uvf8UzNe8mYt3GQ29AL8kng2/pN5VVQuDEi0= X-Gm-Gg: ASbGncvqtww5HSKD24Z2Kx2UJYEYkXkDi2/fTz/52guMg1jXcHyM3G1S+R5NrWTVeho ATSeixeKVEtlZMpIg6g+O8zEWs0FDBe2y4Ox2pX/zoDlblq4usSx+O6z6v6fSxrlZ9un4vWJjr4 G4neqEV3ynQGtN0VaMtg7IURu1BIX6PRkQ7NCB6r0HtZCzqyAw1sAejPtC//zBV87giedrZjKah wOdLrefLkHXfbe5VEl7ARbj6kcKCfG7GoH3AzjLsxKKEa5b7xKsgqrBtPppNzPGVqW3jxc9+ruq ah7MwMqbUHqUw2732DTjL1S1tw== X-Google-Smtp-Source: AGHT+IHOFOqJqaMxE3ADC0JCeH82o6gIoKQpwmMpDhJUTNFG6NWH0EKs8mqdVa0m8D3IMcQ55Fo/2A== X-Received: by 2002:a17:902:cf09:b0:215:758c:52ea with SMTP id d9443c01a7336-21dd77571admr39887575ad.9.1738138373863; Wed, 29 Jan 2025 00:12:53 -0800 (PST) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-21da3d9d98esm93882395ad.36.2025.01.29.00.12.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jan 2025 00:12:53 -0800 (PST) Date: Wed, 29 Jan 2025 00:12:51 -0800 From: Deepak Gupta To: Chunyan Zhang Cc: Palmer Dabbelt , Albert Ou , Paul Walmsley , Alexandre Ghiti , Andrew Morton , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, Chunyan Zhang Subject: Re: [PATCH V5 0/3] riscv: mm: Add soft-dirty and uffd-wp support Message-ID: References: <20241113095833.1805746-1-zhangchunyan@iscas.ac.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20241113095833.1805746-1-zhangchunyan@iscas.ac.cn> On Wed, Nov 13, 2024 at 05:58:30PM +0800, Chunyan Zhang wrote: >This patchset adds soft dirty and userfaultfd write protect tracking >support for RISC-V. > >As described in the patches, we are trying to utilize only one free PTE >bit(9) to support three kernel features (devmap, soft-dirty, uffd-wp). >Users cannot have them supported at the same time (have to select >one when building the kernel). Why do we expect a user won't be using all these three kernel features (devmap, soft-dirty and uffd-wp). I do understand the part that their interaction with each other is mutually exclusive but their usage (from an user's perspective) is not mutually exclusive. So forcing this choice on user at kernel build time is way too restrictive. Additionally this forces distros to carry 3 different builds (they dont know which user is expecting to use which kernel build). As an example if I were running microVMs to host something like serverless (lambda), I could be taking live snapshots and that would require me to enable uffd-wp. At the same time I could be using criu to snapshot some task. Locking in at the kernel build time takes that choice away. IMHO, this should be done in a way which doesn't take away the choice from user. And if there is no choice left from sw workaround perspective, then right approach would be to ask RISC-V to cough-up more RSW bits. > >This patchset has been tested with: >1) The kselftest mm suite in which soft-dirty, madv_populate, >test_unmerge_uffd_wp, and uffd-unit-tests run and pass, and no regressions >are observed in any of the other tests. > >2) CRIU: >- 'criu check --feature mem_dirty_track' returns supported; >- incremental_dumps[1] and simple_loop [2] dump and restores work fine; >- zdtm test suite can run under host mode. > >This patchset applies on top of v6.12-rc7. > >V5: >- Fixed typos and corrected some words in Kconfig and commit message; >- Removed pte_wrprotect() from pte_swp_mkuffd_wp(), this is a copy-paste error; >- Added Alex's Reviewed-by tag in patch 2. > >V4: >- Added bit(4) descriptions into "Format of swap PTE". > >V3: >- Fixed the issue reported by kernel test irobot . > >V1 -> V2: >- Add uffd-wp supported; >- Make soft-dirty uffd-wp and devmap mutually exclusive which all use the same PTE bit; >- Add test results of CRIU in the cover-letter. > >[1] https://www.criu.org/Incremental_dumps >[2] https://asciinema.org/a/232445 > >Chunyan Zhang (3): > riscv: mm: Prepare for reusing PTE RSW bit(9) > riscv: mm: Add soft-dirty page tracking support > riscv: mm: Add uffd write-protect support > > arch/riscv/Kconfig | 34 ++++++- > arch/riscv/include/asm/pgtable-64.h | 2 +- > arch/riscv/include/asm/pgtable-bits.h | 31 ++++++ > arch/riscv/include/asm/pgtable.h | 133 +++++++++++++++++++++++++- > 4 files changed, 197 insertions(+), 3 deletions(-) > >-- >2.34.1 > >