From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) (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 0D53F3451AB for ; Fri, 14 Aug 2026 15:54:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786722858; cv=none; b=B194emb/v+mc+BxvlEATAUrqop+pSu+SkCgHgQRlbmJz0FXLVudB6OEdbHydaakBCXFE35KtbJGtpIrAaJ2jTDicOjuYZXqugOIGb7Fpc8Mr1wUU4JZnVwuAmWq2eXidN1yF3Zo/DGjyjjcAjyI/npTY6n/97lOx0mQPMw9F/uQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786722858; c=relaxed/simple; bh=LR+F9o8z2ArdQWgZKBLhQR4M24y5KNqH0Azx9MV4D8U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GomXMuLPpREvMnzKEW0BgNCPgdO3Ep9TJjlKHZMH8pnGFDbZI34PdRU1e0EJBvdLRC+NykIN6W06rSSuKabpw8Y/Sg8+deE5XHkLCj+BlG2V2r4E9pUwHbiElQek0TnD3s58rW23X8rZtNiPHZfiSfdB4/updudZtlWGn5TtlH0= 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=YEIVV9pU; arc=none smtp.client-ip=209.85.214.176 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="YEIVV9pU" Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-2d3b440b97aso106705ad.1 for ; Fri, 14 Aug 2026 08:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1786722856; x=1787327656; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=Pi8lKrsPGjtKjHhLvrK6PemQZweWipGEphM9Nz2AqhE=; b=YEIVV9pUPKE2x6YeYaLvUUzKEPJlO0A9rjECyiCfQMPJoR8fwZtulyUE9Uo9Lnx3yd f47HpH8fcQ70lGK3aizYikdheqRiCq2mOmRBlcZitRx46bXsTH+wTqYRZi5bqd8UolOL ic47SUWC6EZY61rIUfa8IaOyziXSsqjIXYOg/xc3k6D1pmPYKudpSCHp6Mfl34D5LUV+ xP65EcPvW4m4teWZhDVXTfD96kZay9n61WdRRq4wPXo4xwNUFbVujkQcIR8TmnsB8Hw8 Ux4eSjacxbqXmlxzZGa944Hp8fb/U8NIHZR8rdI8szkDp9W2jHlypfF2rRGr04g6M23n 2nfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786722856; x=1787327656; h=in-reply-to:content-disposition:content-type: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 :content-type; bh=Pi8lKrsPGjtKjHhLvrK6PemQZweWipGEphM9Nz2AqhE=; b=VwLfnY+R2h3geyUwkGSxXJ8dM11PB3jSphugAxn9Do9Urr5hxyid5dsyyg1IYbwauq BjJ5LqHd2G8GYsRZ5obHnvy7E9QfY1VUhWjnkxIfECFlDIyZp52Ws8zL45Wz45eOc6PW box6WHTiiArRDletpf4kUjl5/AiOspCNH/3CzIKdmhyBnj2FzWmXRPXnpz/ViAK5tYvp OYWFuL62eQYZuKR2ZLZ2xe8MRrDlh2MDDdqxC7ai3+KIv1D2tU4pfHiqPl3f1AaoPbQa dhL92KH/8VT3KcC95lIWOnn04gbJE1vhg/VIksgAF9CbgSvvWFBSw1b8t1sxWuUbYv2Y mLbA== X-Forwarded-Encrypted: i=1; AHgh+Rp1Fh+p4hQJSPxyT7YJT2v6TWSL63MQ9AMt1lpWmFRjlyGt0QYzodNAv4SDyyx9Fr0l18BC3EOhu1PxAGM=@vger.kernel.org X-Gm-Message-State: AOJu0YyewR/RJFikp3XnMbCWi0AYkucrVIf7x+5X5RcMXUHMwhHW4Ldx yKUS3VRQ44vh+O45vPiaFcMo3yRn+X9/38ckyZWkkF8KAQ6ifVLoTOz1PdhdcT+ysw== X-Gm-Gg: AR+sD13lrUuunzwm071qhMXvbwwPVA/jSUB9tjo7WherNWYwDXi2W6BjSGCXaAyc/9T Oo13dvAzLx9LC6u7MUJ350O5Qf5V8Z3naxy0AFAvt/vFmiOREF6jGq91E71JTC3ZFoxkOYdfswu cz9qcRlW7nBPtuEJay+h80E5+NRdUQ1fqAHI9ZHG89PUcFD0S3806783LzuGULvqDe8fxATGWS+ KREiW7bp58KaQmKwXwcKVlGnltjOzOoWcTUS9j2kfwQmTr+iqzU6PgaiTh3aWzMp4xiotKrbXrT I648vlfVmZ88pVThas3iBoGEbdO5Z4PHekJj+kHzXh/xT8I/vDtvd7tBJwFDJwK1+okQZfaw0ZA eI1hJHxDerEsPVs3U6rELHLHggjWmyGZMfz8kUVlEhjCqJVhwxgihPHC4Sl/nf6btS6wJJRzk2D z2CMCK4FcRDZaIIWtqsjahAkQ2HQNCbO7g9mhMSDAk4A6xVjhEzCenK8EAP8Atg9kNhgjClR/UV ocSxa54lWvRY8Ka1tW3lDsM8AbowYmQjHGqrQIbkjr9FJN7N6AwQh2A3Po= X-Received: by 2002:a17:902:d58f:b0:2bf:3579:cdaa with SMTP id d9443c01a7336-2d3af24fe17mr9846895ad.10.1786722855608; Fri, 14 Aug 2026 08:54:15 -0700 (PDT) Received: from google.com (210.87.127.34.bc.googleusercontent.com. [34.127.87.210]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-39339d00eafsm1779979a91.1.2026.08.14.08.54.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Aug 2026 08:54:14 -0700 (PDT) Date: Fri, 14 Aug 2026 15:54:11 +0000 From: Samiullah Khawaja To: Alex Williamson Cc: kvm , Alex Williamson , Jason Gunthorpe , Bjorn Helgaas , Kevin Tian , linux-kernel , linux-pci Subject: Re: [RFC PATCH 1/5] PCI: Refuse function reset of an SR-IOV PF with enabled VFs Message-ID: References: <20260812045325.2733631-1-alex.williamson@nvidia.com> <20260812045325.2733631-2-alex.williamson@nvidia.com> <20260814083737.66bb83fb@nvidia.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=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20260814083737.66bb83fb@nvidia.com> On Fri, Aug 14, 2026 at 08:37:37AM -0600, Alex Williamson wrote: >On Thu, 13 Aug 2026 23:22:33 +0000 >Samiullah Khawaja wrote: > >> > [snip] >> >+ if (pci_num_vf(dev) > 0) { >> >+ pci_dev_unlock(dev); >> >+ return -ENOTTY; >> >+ } >> >> I am wondering whether we should return EAGAIN from here, since this >> function is used by vfio_pci_core_enable() during open and it doesn't >> fail the open on ENOTTY. Basically whether we should allow the user to >> reopen the device if the reset was skipped previously? In the previous >> instance of open, the device was setup with vfio/iommufd and the vfio fd >> was abruptly closed and the reset was skipped. But the device went back >> to the IOMMU default domain and that is probably an Identity domain. If >> we allow the device to be opened and re-enable busmaster without a >> reset, is there a chance that device would continue to DMA based on its >> previous setup/context? Probably unlikely? >> >> Note this is different from the current vfio-pci behaviour where device >> is always reset during close. >> >> Maybe thinking with too much paranoia about it :D. > >Devices are only ever opened into a user owned domain, the IOMMU >context switch happens before this and regardless of the reset. Close >also disables bus-master regardless of reset, so there's no risk of Yes the close side makes sense, I was more concerned about the reopen. >ongoing DMA if the device is placed into an identity domain between >close and re-open. > >Actually, I think -ENOTTY is a leftover from a previous iteration where >this test was pushed into the individual reset methods. -ENOTTY allows >continuing to the next reset method. With the test guarding all the >reset methods in this version, we should probably use -EBUSY. -EAGAIN >would conflate the try-lock contention error, which is actually a usage >race, versus the PF is not in a state to handle the request. This sounds good to me. > >If the user owns the PF, as evidenced by them being able to get to >vfio_pci_core_enable(), and reset is blocked by the SR-IOV state of the >PF, I think there are arguments both that the user implicitly opted in >to the best-effort reset, as well as a use case that allows the PF >driver to fail and re-open the PF demands this behavior. That is fair. Thanks for clarifying. Sami