From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6A25B2566DA for ; Wed, 5 Mar 2025 20:29:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741206566; cv=none; b=mU5NNgbJAoJFcMXu7snvg5W6qmIpAGIah0vcug/5iG+hAWNOQaCojRyry6X4C8PKyZ2Wo494LbXMchJd6+dH/yHITB7WPAWtMzY5qrwj08MY0Q5xRTq3yMFfuwMl/uKcbGamDbb3JvSA4QqBeaKaxh6ugcz8kyF+f/ibWs1zdP4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741206566; c=relaxed/simple; bh=2YVWFyfkS3CQD7maRiKkuIwzWsd29P7CBa7g4mJPku4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=HhUNUWfLFOp32kBQ86QxsUJ7nHRMcrikMUNFhSa6xL+aFHeGanN0BmBrmRlkS7KxJkphWkAbZIEeiZzQckx+qJ82/+L4rgb1PG+0rTcee1OnJsJIb/HIRkBCa6Bx28zA45LvvdqZfJ0jeQb7NcIamIUFNBjjFpR12J3+YlV43/o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=JVMpXpZ/; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="JVMpXpZ/" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1741206563; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=oalwxEzZmbkO3BEyiEOSG53V47EPWxAbwPV2MRYZBwA=; b=JVMpXpZ/DndCfCWriD2L12bVh2sJwWa0L7oO8mrn5t51PUbpABztdelvpHF73I3ZrYbTFM KIz8fs6Q+pTY7dzBrJMhZcPHZG0NwEDupAPUgSF6c+iRQbnyADgQg3C0q6HpPybcy+lHBA 8uLtB7iTnTxFpJlyEXFPmxzAvzuv1+0= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-629--bS8X6h-Oy-OZwiQbUbp4w-1; Wed, 05 Mar 2025 15:29:22 -0500 X-MC-Unique: -bS8X6h-Oy-OZwiQbUbp4w-1 X-Mimecast-MFC-AGG-ID: -bS8X6h-Oy-OZwiQbUbp4w_1741206561 Received: by mail-qv1-f71.google.com with SMTP id 6a1803df08f44-6e8e8dab926so19358346d6.1 for ; Wed, 05 Mar 2025 12:29:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741206561; x=1741811361; 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=oalwxEzZmbkO3BEyiEOSG53V47EPWxAbwPV2MRYZBwA=; b=BHpYgkpzvadL5WnsIhDZdtcYjmJrB2sgZP8VKJ+Pm11MiTygZjTmOq4azVI883zlq+ wBVzBGggvbPBw7yBsSWlJqOjnOMK9zT3g6eZ44zjHU4ttKHLidrhFiJTTU26TCNB9Hnh b2+XNJJOt/E10mLLcWMTG8fbOLyt9n67FMveoUcYyZW0ILz0d8QOLvZH9sWC5YctPvCS VuMQKHcCAZNUO28eSBUYfJDAl2F01TuMVuDXKuaAyAGOwA2e0qENrd5lusxXWTsc32g5 W641JPvh8g+pE5vlyt8AyPwIQRz2bVeh+kG0Sdt4P+NJ9/0WQhaALbX0m4FgkHy93ySb ilvw== X-Forwarded-Encrypted: i=1; AJvYcCVxqZJxLKNoIit9Nh7sjh14dPlGhQ52rTNIs4ycGNo0xvPcNTgI3r1C9s51Mn8r9t3r/IupP8QBI7SRbps=@vger.kernel.org X-Gm-Message-State: AOJu0YytmScVmwWycPKlKJgoTHe5WJvuIqMEhSawc6R6L0Ds89ApSujq yE6aCeWY0YJn4yHnrAZd979V1/23Dxh5paQ2ZUHDHyl9DNVHXRqRSn0sBJuRJAUcO00x6T8LKpZ MxOKC8AZ34Mu5YGxpM4HmwXXDEXb30eogjb20mbMjCsNK6rKXM0SWp0Wi8MmxkQ== X-Gm-Gg: ASbGncuCsuGDL1/fniFevGaeqc7MzuIigddmBM/heMMp2eJaCrIPC4WL+lrfOGib/ik FXhSHvO+iBRb3cetAx6Fz8cWq/aKD+CtkkXjdW2MNrlnj1BlYxV7V92XozltVR6gLnQ99aNNLwU G+pElOCuF6ay9Z/xzdf+rPqm1KDXdxhAAZEsbhMuiLItrd04PFtjYy6NsY5VtNmoH18ajEjPSPa j2aRQ0yOcI/cLL3ZdTq94qnrQwfHDL8GrbR7RkWo9HHywRigQqIBZhfAqRlWSplOso5mv4JBDPy eELb1Bk= X-Received: by 2002:a05:6214:21e3:b0:6e6:9b86:85d0 with SMTP id 6a1803df08f44-6e8f46d5cd1mr8080036d6.8.1741206561649; Wed, 05 Mar 2025 12:29:21 -0800 (PST) X-Google-Smtp-Source: AGHT+IEzj3VnzDaaIbvAFjVufn5nGxmexz91QgKSdKtxQ40yVUP2gqR5kYn2qDKbFG2xC9ZTZ7Hnpw== X-Received: by 2002:a05:6214:21e3:b0:6e6:9b86:85d0 with SMTP id 6a1803df08f44-6e8f46d5cd1mr8079756d6.8.1741206561335; Wed, 05 Mar 2025 12:29:21 -0800 (PST) Received: from x1.local ([85.131.185.92]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6e8976cc9cdsm82983196d6.88.2025.03.05.12.29.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Mar 2025 12:29:20 -0800 (PST) Date: Wed, 5 Mar 2025 15:29:17 -0500 From: Peter Xu To: James Houghton Cc: Nikita Kalyazin , akpm@linux-foundation.org, pbonzini@redhat.com, shuah@kernel.org, kvm@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, lorenzo.stoakes@oracle.com, david@redhat.com, ryan.roberts@arm.com, quic_eberman@quicinc.com, graf@amazon.de, jgowans@amazon.com, roypat@amazon.co.uk, derekmn@amazon.com, nsaenz@amazon.es, xmarcalx@amazon.com Subject: Re: [RFC PATCH 0/5] KVM: guest_memfd: support for uffd missing Message-ID: References: <20250303133011.44095-1-kalyazin@amazon.com> 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=utf-8 Content-Disposition: inline In-Reply-To: On Wed, Mar 05, 2025 at 11:35:27AM -0800, James Houghton wrote: > I think it might be useful to implement an fs-generic MINOR mode. The > fault handler is already easy enough to do generically (though it > would become more difficult to determine if the "MINOR" fault is > actually a MISSING fault, but at least for my userspace, the > distinction isn't important. :)) So the question becomes: what should > UFFDIO_CONTINUE look like? > > And I think it would be nice if UFFDIO_CONTINUE just called > vm_ops->fault() to get the page we want to map and then mapped it, > instead of having shmem-specific and hugetlb-specific versions (though > maybe we need to keep the hugetlb specialization...). That would avoid > putting kvm/gmem/etc. symbols in mm/userfaultfd code. > > I've actually wanted to do this for a while but haven't had a good > reason to pursue it. I wonder if it can be done in a > backwards-compatible fashion... Yes I also thought about that. :) When Axel added minor fault, it's not a major concern as it's the only fs that will consume the feature anyway in the do_fault() path - hugetlbfs has its own path to take care of.. even until now. And there's some valid points too if someone would argue to put it there especially on folio lock - do that in shmem.c can avoid taking folio lock when generating minor fault message. It might make some difference when the faults are heavy and when folio lock is frequently taken elsewhere too. It might boil down to how many more FSes would support minor fault, and whether we would care about such difference at last to shmem users. If gmem is the only one after existing ones, IIUC there's still option we implement it in gmem code. After all, I expect the change should be very under control (<20 LOCs?).. -- Peter Xu