From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.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 2183E303C93 for ; Mon, 24 Nov 2025 13:57:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763992649; cv=none; b=K6lgRbUJ8LnbiNFvQhjofbBMG6HgfF+2pGWKr5GWVM+D1DxEXIwPfGahekCTzZ85QbQag0XL6neo8lvG14IrkqOzyZ0Qbhl9jYJx/PP+L5I+JJTNqtt647ni6McFv6jRej3uD5IqnFyvPF8Ukk+eV74YC7c9MagZ8VQEjR6ZGCo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763992649; c=relaxed/simple; bh=/LmKaHff4nntcfS7Wy3MKDDclaL6d71CVaMNMyFBJbw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YDLATiY/Ys0w5L9u1d8fWWZDgnQqynvLNw7Obp0yDXA1MBLSvss1rqQycjMXhYMGazbwnm8BqtV6dtNxwzt80mgSlF5/+sflUGJEov3KrE5aRL/FtXveR7dKXuq3EKUDAswmQ5GG9YoR+8HZ8BsdnSzwQO3+e5NOBb/bdKv7oWE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=EaMDmlC9; arc=none smtp.client-ip=209.85.222.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="EaMDmlC9" Received: by mail-qk1-f170.google.com with SMTP id af79cd13be357-8b2d32b9777so573847985a.2 for ; Mon, 24 Nov 2025 05:57:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1763992647; x=1764597447; 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=FzGPtEalSLjcMtqSWV6EEbKRU29iQ739nTvOMeKCmHo=; b=EaMDmlC9UOBcx1QWZTOUOiS/T4wkfYrAXLfBL1hSpscZb5Pxcx6SSduoqB2zMn1qKm qUFZbdYBulW2En/JqAVG1QR9OA0LjnnQFtCLSWikpC79vPUkiYQup+nABQ0dkazPZLBJ tb1duaPx3pG2nEJupXyuiI5/yekYcFhTRiF2d6SmtovLJtLeiKU5MvqMDQcJCpgh2F2A 4FYetL0FHE4et25z0xfuZxft1c6dAkTxS5JB37xB9aMJPd+cXgu2v5BDNNUchsmQ/pAq 9vNnhNlpncgnUhpi4LjbsAmCu1pjhhSvEHf+sBeNXgFMHIJXAXklc6RkdEPIxauizUp5 yXJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763992647; x=1764597447; 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=FzGPtEalSLjcMtqSWV6EEbKRU29iQ739nTvOMeKCmHo=; b=s3g0YTakbeGdZCXN3PjRZEph/Tn64JliPAaBF2mlLw6KFlfZnpB8LmBM3g5Rx98Yu7 M94onAJduT+cXYfF3JiMuf09xgwAVjktXRdLlnRhonf7++eypsZhhCAfglzygJTP0VXt 4kxWFooLHAKy28wWSxiGhjkftpNM8HjeI/ikv2g+YeXzcjFMLlUrp+8wjHJ3eyr6rYrh AsZMuoDaHf+5CwqbzJQPuI8rvM14JCs+zZCnYrFC33Ef+VxzhhiY0VGn66Iiqz8RRnJH OTHjB3AbZig3bGw5leYoQp+tVMIAhCZqNOa8I1B2EHtBtZsx1i3bggFcxGiZJgKpa9n7 HQgA== X-Forwarded-Encrypted: i=1; AJvYcCVWyMyDzmyybUEaRyuI+VZC4estK6QnaKmg0cfacEmA7myusG+mKuvV/uD3hMjLvqBNxbeH50hgM0LDlDc=@vger.kernel.org X-Gm-Message-State: AOJu0YzVmq1UEI27aWtp2HXzqnAG7IoAtydGMTLTmdry7AaXn+9JEAA/ hAIHrmieWQBtrz1rNCMJtrCkxxA6ndsAJLgDIR/Hx7OTo8fFG5VNUaZNmc85MGVOei8= X-Gm-Gg: ASbGncszY+XzPjLnboQ1H9jMsRpsgx4e9ZQsgOUqNgzNuIfgErC0+5Eesv5IhWMfUGn 9duu60Zvv1ieBv7purLz9e1ivl8ZtnMJM+5YD6+V+/j3EE2OuQFzHtowun3saH8HzQkZmD099K5 Yyvr20tR6T7O/CCsDUUp6kajIIBECVaRdy/LBCyGd27/ax+MO3VgsQfiN5TJSEen311aKYehyCJ Ia4KKd9tlekBLf9hV7J0tGILr6Bb0yYo8k48xlyZWuo0rwlJYQMPq1A/P8igtMx6IuMCuiazH97 grUunLuuy6SP64UpcA4Pg01ieOF1s9/2sqD2oRNQCTFbBozHtVmaJ/ZEj2tYLWZaF7zdkgMW1nv L9grrMJ0UYh2psFPsfWVwaxXOdO4LVsUOhjIgJAsl6jUL9D0ABTNFygji3lRa6FJl6C9J3QG028 XxhVoY8actNf99OFkRq4vMs7CfOmMiDipy4q/ujKf8sd3ehTNG9k1P7Mrp X-Google-Smtp-Source: AGHT+IEPe/syhuKX3O6wJfzn2tFHtIYyLXPv4mSXMhK4WSxfHaFJjzLBvTrU3KR8SZjQD2Av3g8vkw== X-Received: by 2002:a05:620a:29d0:b0:8b2:dec7:d756 with SMTP id af79cd13be357-8b33d4cafd0mr1624311585a.66.1763992646911; Mon, 24 Nov 2025 05:57:26 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-47-55-120-4.dhcp-dynamic.fibreop.ns.bellaliant.net. [47.55.120.4]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8b3295de540sm943003085a.42.2025.11.24.05.57.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Nov 2025 05:57:26 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1vNX4H-00000001uYc-21zH; Mon, 24 Nov 2025 09:57:25 -0400 Date: Mon, 24 Nov 2025 09:57:25 -0400 From: Jason Gunthorpe To: Leon Romanovsky Cc: Danilo Krummrich , Peter Colberg , Bjorn Helgaas , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?utf-8?B?QmrDtnJu?= Roy Baron , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Abdiel Janulgue , Daniel Almeida , Robin Murphy , Greg Kroah-Hartman , Dave Ertman , Ira Weiny , linux-pci@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, Alexandre Courbot , Alistair Popple , Joel Fernandes , John Hubbard , Zhi Wang Subject: Re: [PATCH 7/8] rust: pci: add physfn(), to return PF device for VF device Message-ID: <20251124135725.GO233636@ziepe.ca> References: <20251119-rust-pci-sriov-v1-0-883a94599a97@redhat.com> <20251119-rust-pci-sriov-v1-7-883a94599a97@redhat.com> <20251121232642.GG233636@ziepe.ca> <20251122161615.GN233636@ziepe.ca> <20251122185701.GZ18335@unreal> <20251123063456.GA18335@unreal> <20251123111823.GD16619@unreal> 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 Content-Disposition: inline In-Reply-To: <20251123111823.GD16619@unreal> On Sun, Nov 23, 2025 at 01:18:23PM +0200, Leon Romanovsky wrote: > > >> That sounds a bit odd to me, what exactly do you mean with "reuse the PF for > > >> VFIO"? What do you do with the PF after driver unload instead? Load another > > >> driver? If so, why separate ones? > > > > > > One of the main use cases for SR-IOV is to provide to VM users/customers > > > devices with performance and security promises as physical ones. In this > > > case, the VMs are created through PF and not bound to any driver. Once > > > customer/user requests VM, that VF is bound to vfio-pci driver and > > > attached to that VM. > > > > > > In many cases, PF is unbound too from its original driver and attached > > > to some other VM. It allows for these VM providers to maximize > > > utilization of their SR-IOV devices. > > > > > > At least in PCI spec 6.0.1, it stays clearly that PF can be attached to SI (VM in spec language). > > > "Physical Function (PF) - A PF is a PCIe Function that supports the SR-IOV Extended Capability > > > and is accessible to an SR-PCIM, a VI, or an SI." > > > > Hm, that's possible, but do we have cases of this in practice where we bind and > > unbind the same PF multiple times, pass it to different VMs, etc.? > > It is very common case, when the goal is to maximize hardware utilization. It is a sort of common configuration, but VFIO should be driving the PF directly using its native SRIOV support. There is no need to rebind a driver while SRIOV is still enabled. > > You're mixing two things here. The driver model lifecycle requires that if > > driver A calls into driver B - where B accesses its device private data - that B > > is bound for the full duration of the call. > > I'm aware of this, and we are not talking about driver model. Whole > discussion is "if PF can be unbound, while VFs exist". The answer is yes, it can, > both from PCI spec perspective and from operational one. This whole discussion highlights my original feeling.. While I think it makes alot of sense to tie the VF lifecycle to the PF driver binding universally there are enough contrary opinions. > > At least conditionally (as proposed above), it's an improvement for cases where > > there is PF <-> VF interactions, i.e. why let drivers take care if the bus can > > already do it for them. Drivers like mlx5 have a sequencing requirement during shutdown, it wants to see SRIOV turned off before it moves on to other steps. This is probably somewhat common.. So while it is nice for the bus to guarentee it, it probably also signals there is a bug somewhere if that code gets used.. Jason