From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) (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 A43F527FD75 for ; Tue, 16 Jun 2026 00:42:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781570545; cv=none; b=JDFD2LTexDUgPhczOWqMypUHwl5A5MJfL2dF8CNucaiHwcNQjHoZq3ZdIVWzx33Vjy8pEVWOp+KKiL+IiM5PCfAZ15/BU9qlYYXYGiQ/uKI42t+HzOpKbtGkNfIm7EtuRv8l6Bt597a2e/5OA7gKf1jR+0tZWRMDWkBhdm1h1t4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781570545; c=relaxed/simple; bh=dLd2xq2uaf3rRXOHvRSNS0csxsbcSNNyU4+pJRavd9E=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=HYTgPLxl25RYv/2b9ZCNkPhLB3ABnIpYbNRxA7xq/wv6BigeiEuP6OIEI/PcPlSxxypSJ+Wwon/dLuM00jfE6YntgVv7d17SyDC8x6Cj/G0YcOa15VqHpfd7XqwugQxZ3lNcJBCcKRh/oAT6iEjuCxhttelLfvAciCSpTJ46fR8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=syowSQf8; arc=none smtp.client-ip=209.85.214.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="syowSQf8" Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-2c67ea316caso12835ad.1 for ; Mon, 15 Jun 2026 17:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1781570543; x=1782175343; 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=dLd2xq2uaf3rRXOHvRSNS0csxsbcSNNyU4+pJRavd9E=; b=syowSQf8wLSWGtS1PgGodgassz1O0d3yWQC/H8bw1NwhJXnr2zJeiuj2E9Ro7P8b6l 0sKRW0UZFDTu+eESKF29TzoeA+btPajRdmHAwn8Fq68xybv5XIGq84mQ5N/mCzA9iv90 tqL76uIuG5kg5s11jGw7XA/DJp7SuL2b7rLOnd+J61Tp2e9hVRkxujRfT3N8Z4G5V+iT JRdBHxN17iGa6R1QsD9eJ30qxHswfPElKqYT+dbJCj9baxjbVpYy0TVxWpgBH9lXGUre FFWVCLGYk9RnLU9bmUm53V0robpx5+adag8sZtrLrwcaCjFlJYvIEQjn9orrqr/AMG8f TzPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781570543; x=1782175343; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=dLd2xq2uaf3rRXOHvRSNS0csxsbcSNNyU4+pJRavd9E=; b=qqkEl0OFNN84N2WOHdYONuAm6pjOzufoECGKvxGtpVx4FhUO1haoGIiK4xB9Q8k4G3 wGrG/ZCd9UuSZxHBi6b/1MvUKNg5ARVeNOu048kNElyFWyMG2bE2rs0GlFqUahB876jM 4MFQt9UFJNBTh6342rnzZGdIQfoXnYJmWftxGlq9+KX/UHknsbO0SE0eyz/hQ0/3wPho Q2FDVx3zhGI2MH1fXoTv7xx3JYq21RpWFLBxIg/2eL1USpecVtgfOns4D2I1Dr8gBROQ LWBwojnQIHuxxmB+cYiRPmkehvG2tWVQr07wEPBIxx31VjWaijRIbVpBxRBYwhEsuweD +i+g== X-Forwarded-Encrypted: i=1; AFNElJ+RqjrXLpyvdPrBTQtuTb3Lh1hry/jvIwygnOumt1b5MFQdH/9h8gzVcyW/5aonmKCSzGFBvmYX2fJAhzc=@vger.kernel.org X-Gm-Message-State: AOJu0Yxoh63UGL6Ab8G3xez0EyYN4gK+nD/KLXJFa75UJmfDXqewIW3J 5owa4eaQRXmGlN9xIWBpXprpDvZrHchr7Zs8IjZvb1HNxheTv6N/FagcjH3QLPPxpQ== X-Gm-Gg: Acq92OFLkG2pW3FJKLI8yr6Slcwc9k1Z1ElAsblVzfsQ/oH1EmMXACOIIlimisCes0q k1UqRWtIQKv8BpmsOs8U0yD6l3poqTz0QnC+NSqa3CJcWQUIfSDYhAIHsT04aO99AY2kImkdIji RsCoSym2CbXGg9sr/E88UzAvFYpbS6H+DWlFRG0fhFMojC7Nv8mpFQactxCv3dYSMoZ4oVjhdOP BPd1qpaITteUd2No4LIGmYxh/cCZk+jvFf5aSjUQMXdFDW0kCDlMKeLzj4hDXO4k3r+dP2RoadZ yqqTZ44YHNWvzJ47ViuaXUW9sjBI66ZeejS2TQlqjf3VcLWMAUtc5zIVnUEcL4zVOx1KCNLZAl+ lyu4jxwCmpgeco5UWW9M9Vb8im89kgN/1/MyixcqlPFIOrzNU2sqme0W/Ip6KJAkLdvQwlLSZvk bCXGeFEnHrx1m6s93zkYQGYj3kw5FjTpjQ0fUtZ4cKLLaC33EPTSliSv4aw+GxPwO6INnDRl5Vz 88HACzYv0pcVdeWQBM= X-Received: by 2002:a17:902:ef02:b0:2b4:641a:6b7c with SMTP id d9443c01a7336-2c69c1d4b35mr692755ad.13.1781570542499; Mon, 15 Jun 2026 17:42:22 -0700 (PDT) Received: from google.com (25.75.145.34.bc.googleusercontent.com. [34.145.75.25]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c8661b5e509sm10014682a12.3.2026.06.15.17.42.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Jun 2026 17:42:22 -0700 (PDT) Date: Tue, 16 Jun 2026 00:42:19 +0000 From: Samiullah Khawaja To: Pranjal Shrivastava Cc: Jason Gunthorpe , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Bjorn Helgaas , Logan Gunthorpe , Alex Williamson , Kevin Tian , Ankit Agrawal , Matt Evans , Vivek Kasireddy , Leon Romanovsky , Shivaji Kant Subject: Re: [RFC PATCH 0/5] vfio/pci: Support ZONE_DEVICE-backed P2P Registration Message-ID: References: <20260610151853.3608948-1-praan@google.com> <20260610162848.GO2764304@ziepe.ca> <20260611221447.GH1066031@ziepe.ca> 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: On Fri, Jun 12, 2026 at 02:50:18PM +0000, Pranjal Shrivastava wrote: >On Thu, Jun 11, 2026 at 07:14:47PM -0300, Jason Gunthorpe wrote: >> On Thu, Jun 11, 2026 at 02:40:17PM +0000, Pranjal Shrivastava wrote: >> > On Wed, Jun 10, 2026 at 01:28:48PM -0300, Jason Gunthorpe wrote: >> > > On Wed, Jun 10, 2026 at 03:18:48PM +0000, Pranjal Shrivastava wrote: >> > > [snip] > >Yea, that's going to be tricky.. I'm thinking if we can have a zap model >there somehow? If the device is gone / going through a reset, we can >handle the refcounts accordingly? IIUC zapping will only work if userspace is using these, but if you feed this memory into another device through NFS and the pages are pinned by gup (or that device) then the dmabuf move_notify/revoke logic on device reset will be tricky as now the pages for that device BAR are pinned. > >> >> Come to think of it, since the sysfs API cannot do that in the way >> VFIO wants I actually think you can't use it.. > >Ack. Baking this into the VFIO DMABUF allows us to enforce the right >lifecycle. > >My plan for RFC v2 is to add a flag like VFIO_DMA_BUF_FLAG_ZONE_DEVICE >to struct vfio_device_feature_dma_buf which allows the caller to opt-in >to ZONE_DEVICE backing specifically for that export. > >Does this opt-in flag sound like a reasonable uAPI or do you see any >concerns with this direction? > >Otherwise, as you noted, the lifecycle and the mmap path remain the main >problems to solve. > >Thanks, >Praan Sami