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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 0F762E7DEFA for ; Mon, 2 Feb 2026 15:55:16 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 5F48710E503; Mon, 2 Feb 2026 15:55:15 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; secure) header.d=ziepe.ca header.i=@ziepe.ca header.b="CT6MM/Lw"; dkim-atps=neutral Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1E52C10E52B for ; Mon, 2 Feb 2026 15:55:14 +0000 (UTC) Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-5014b7de222so48258471cf.0 for ; Mon, 02 Feb 2026 07:55:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1770047713; x=1770652513; darn=lists.freedesktop.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=ALEv89D4GoCyBIrWNO6jRp/YUrS6bKKk+NOOQflmefI=; b=CT6MM/LwSQWyAUZ8oUbVcclHf/cLWGhKvV0HWN73HafdAcBzN6yWuSInG57yn5ugRI uWrq5pzxkqkRNRen6m+iV8Csz6fR+53J6tfrnH3enePXF7g99XDW2FeARZkkWtuGJGVd 1HMqiMhV91D++RIi4k/h0lim3aGjbhK4SsOKAZhBiW8ICLmTF52r5BnTCKfh2PlsM0bt NEIwjYoB6MKekoNb5n/KZc56939e+Hdj2p3zwL2Upy7cN96e/nh9leVHqcwPDOJArqrO JbAVBqFy76XxaCyfyhZmm4Xn26BiAtf5VRnaCTfainddI+iiwHFPy0pgWl2qHUq3XiqE wQeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770047713; x=1770652513; h=in-reply-to:content-transfer-encoding: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=ALEv89D4GoCyBIrWNO6jRp/YUrS6bKKk+NOOQflmefI=; b=ALDV4oNxYp7A+rbZG6t7s+VkTCelGtUzvDmVhM4KUugM4hRu3pmLrIjupe/5LFy3Mx A7OOq9wae6sSu/LiWX9T7FHcPGlHK6iIUKK0Y57H6f/gOovTeOvmzRgUvX2mJHfsSykD yvD7NRXoOPGZNwRPU+NzyH0+55cU1SPfcOCPzCY70dTkA02D0diqkD2lZ1dTAgqp/L0a F9IHWBcxyWsTr+1GghQ8lwGonmhiMjcZ+Q+lXrgMfAjfErM/R70rLCIp+mtGgaklT0bx feenZwcfIv3bGvZ6JuZsI6ssU1V+mKvhQPllFpYe+5uMzRD9v8vkjDOHnUS/PNDHxhIP ulEg== X-Forwarded-Encrypted: i=1; AJvYcCVgJgbDBeeNXR67VpDxQg1NC4ur2okBaDdbOyBDwZjhMK5LAm72ANAlDRBk9xhJd4T+1JSrhDBHSJU=@lists.freedesktop.org X-Gm-Message-State: AOJu0Yz71dZteq4lEfe+2ViJZsCOxNN47QK2mXrLyUYykbAKx2Ta9Agi I6xNvRJC9cQsnVH9XFY1vEqncu8r8lxXOgA+9fnIPJL8hW6VnpMeZJZlj2zBf45q9wA= X-Gm-Gg: AZuq6aLIK87HxAOY3rLsYI8qcVexDa0MG+GyeonQqLIjpQNDnGfeydxiibDpbDaFUr8 LWCuej5OSfsRiKbGptVl8s80TsIJJRtB695ZXnTn8AY0jBav1KOyK9Ml4spbHy6HqpxXkRSvi41 b3lyhCNOobv7W4rXV7uxwj7XGqMpMcIkBARmugd5VmrbSqY+hwj97QwlZFGM5t8z9nOxAGRte6d ipLu1Vi5k0zs9/azVYF4TTJ3yEeoho6AT7AprP1GCW3vphLrGE+3tbIOjOvtHx8VflWXqP2YAEO YNubCCVhzY3mkcqeMJ6ZIAkJLCzZd6srNJX8alFMphPnU9DnVCn3uef5u7lS6TTytsXuCQYSeVd hRoMb0m8pE4WeFFsbkIkajRNy9K+jRjGAG2Vm9Xrx9h6G7jv+SSfp2pTOuyxx7V19NeDofUl6f7 nA/UWUAA6MX2k8mwMGNfuPPJVBEcX4kwOh00zPuHeS+n6xGZuzY/ZkGVJ6+aV0NNVYtLA= X-Received: by 2002:a05:622a:1a82:b0:4f1:dfc8:50b with SMTP id d75a77b69052e-505d22b2818mr153088161cf.76.1770047712810; Mon, 02 Feb 2026 07:55:12 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-112-119.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.112.119]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-50337ba3997sm107174411cf.17.2026.02.02.07.55.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Feb 2026 07:55:12 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1vmwGd-0000000FWiw-2z4k; Mon, 02 Feb 2026 11:55:11 -0400 Date: Mon, 2 Feb 2026 11:55:11 -0400 From: Jason Gunthorpe To: Christian =?utf-8?B?S8O2bmln?= , Alex Williamson Cc: Leon Romanovsky , Sumit Semwal , Alex Deucher , David Airlie , Simona Vetter , Gerd Hoffmann , Dmitry Osipenko , Gurchetan Singh , Chia-I Wu , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Lucas De Marchi , Thomas =?utf-8?Q?Hellstr=C3=B6m?= , Rodrigo Vivi , Kevin Tian , Joerg Roedel , Will Deacon , Robin Murphy , Felix Kuehling , Ankit Agrawal , Vivek Kasireddy , linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org, virtualization@lists.linux.dev, intel-xe@lists.freedesktop.org, linux-rdma@vger.kernel.org, iommu@lists.linux.dev, kvm@vger.kernel.org Subject: Re: [PATCH v5 4/8] vfio: Wait for dma-buf invalidation to complete Message-ID: <20260202155511.GI2328995@ziepe.ca> References: <20260124-dmabuf-revoke-v5-4-f98fca917e96@nvidia.com> <31872c87-5cba-4081-8196-72cc839c6122@amd.com> <20260130130131.GO10992@unreal> <20260130135618.GC2328995@ziepe.ca> <20260130144415.GE2328995@ziepe.ca> <20260202151221.GH2328995@ziepe.ca> <44ec9689-045e-401b-b9cc-17abdd938bc7@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <44ec9689-045e-401b-b9cc-17abdd938bc7@amd.com> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Mon, Feb 02, 2026 at 04:21:50PM +0100, Christian König wrote: > > I admit I don't know a lot about VFIO PM support.. Though I thought in > > the VFIO case PM was actually under userspace control as generally the > > PM control is delegated to the VM. > > > > Through that lens, what is happening here is correct. If the VM > > requests to shut down VFIO PM (through a hypervisor vfio ioctl) then > > we do want to revoke the DMABUF so that the VM can't trigger a AER/etc > > by trying to access the sleeping PCI device. > > > > I don't think VFIO uses automatic PM on a timer, that doesn't make > > sense for it's programming model. > > From your description I agree that this doesn't make sense, but from > the code it looks like exactly that is done. > > Grep for pm_runtime_* on drivers/vfio/pci, but could be that I > misunderstood the functionality, e.g. didn't spend to much time on > it. > > Just keep it in the back of your mind and maybe double check if that > is actually the desired behavior. I had a small conversation with AlexW and we think VFIO is OK (bugs excluded). The use of the PM timer is still under userspace control, even though a timer is still involved. Basically there are a series of IOCTL defined in VFIO, like LOW_POWER_ENTRY that all isolate the PCI device from userspace. The mmap is blocked with SIBGUS and the DMABUFs are revoked. The VFIO uAPI contract requries userspace to stop touching the device immediately when using these IOCTLs. The PM timer may still be involved, but is an implementation detail. Effectively VFIO has a device state "isolated" meaning that userspace cannot access the MMIO, and it enters this state based on various IOCTLs from userspace. It ties mmap and DMABUF together so that if mmap SIGBUS's the DMABUF is unmapped. I understand your remarks, and this use of PM is certainly nothing that any other driver should copy, but it does make sense for VFIO. If there are bugs/issues we would continue to keep the overall property that SGIBUS==DMABUF unmapped and only adjust when that happens. TBH, I don't think people use the VFIO PM feature very much. Jason