From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 68A7186342; Thu, 2 Oct 2025 15:11:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759417868; cv=none; b=eP8aUtuOG8BCRSgNdmlmHLa4truSAuPSnM/MyH/RKZt+9B3n1WJ9D+cq+hngxHJDRbJfEqqNFvrMjAZydjn8b8GvRyOkYV234hdbhJHVrGsu9nD4+9EWErPJMrYZJdNY+AzU6TV2pazOk4sCv2PhgOa+qjCQzpl9MRt8/4ggrik= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759417868; c=relaxed/simple; bh=FNclR2C69WQjyAgJd3PWTF23QQxMqsFUS9Q5YQBoudQ=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:Cc:To:From: References:In-Reply-To; b=fWwXIKIVDaQwaR92ZuWrcCAlnPjIxPIA3kJkGGsCWoPOZT6CjNMRcAK2QeTZ7VavCMD+Rrb48fMwaHq3kL1/7jnK5b0WBgzt4sl3X1WGFboK5T52G5nWuuepFxT956tyTVH4OdlDRZFJWJFvEZ/6gPt5khvRv63/D0WWkMSBlaY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=b7LAEI6A; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="b7LAEI6A" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0A8D0C4CEF4; Thu, 2 Oct 2025 15:11:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1759417867; bh=FNclR2C69WQjyAgJd3PWTF23QQxMqsFUS9Q5YQBoudQ=; h=Date:Subject:Cc:To:From:References:In-Reply-To:From; b=b7LAEI6A6X546xyoF4Ubb8NI3YdGNvaf/frUPbRe5r73qhmkrRjcLnf/9Lbbl05x1 bceaUsBFQNzE+rDRu+V+2H/e/ibmjucWQvWLj1U5YnwDZmfg2fOroR+TpcUwqsFbGK AUNsL/ekG3Ksyie+AtPSMbscI1/ffKm24o2Q6lhfdJoMo/JDZO3PJKoAn7BpOcpO47 gYjqSYKmpIDbQ6iKO0owh/TeE4cZF3BWlJQ4TZc3gB2EnzP6jVkO/Qz7jTlloYYn+p 2n8nv942OpFmUZbjSSVNs2qwMEyzQYidZcNpQuSHHFGwGY9xI52RlmA5jOyMyRavCG +Py3BykTxtXAQ== Precedence: bulk X-Mailing-List: linux-pci@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 02 Oct 2025 17:11:01 +0200 Message-Id: Subject: Re: [PATCH v2 1/2] rust: pci: skip probing VFs if driver doesn't support VFs Cc: "John Hubbard" , "Alexandre Courbot" , "Joel Fernandes" , "Timur Tabi" , "Alistair Popple" , "Zhi Wang" , "Surath Mitra" , "David Airlie" , "Simona Vetter" , "Alex Williamson" , "Bjorn Helgaas" , =?utf-8?q?Krzysztof_Wilczy=C5=84ski?= , "Miguel Ojeda" , "Alex Gaynor" , "Boqun Feng" , "Gary Guo" , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , "Benno Lossin" , "Andreas Hindborg" , "Alice Ryhl" , "Trevor Gross" , , , , "LKML" To: "Jason Gunthorpe" From: "Danilo Krummrich" References: <20251002020010.315944-1-jhubbard@nvidia.com> <20251002020010.315944-2-jhubbard@nvidia.com> <20251002121110.GE3195801@nvidia.com> <20251002123921.GG3195801@nvidia.com> <20251002135600.GB3266220@nvidia.com> In-Reply-To: <20251002135600.GB3266220@nvidia.com> On Thu Oct 2, 2025 at 3:56 PM CEST, Jason Gunthorpe wrote: > On Thu, Oct 02, 2025 at 03:03:38PM +0200, Danilo Krummrich wrote: > >> I think it's not unreasonable to have a driver for the PF and a separate= driver >> for the VFs if they are different enough; the drivers can still share co= mmon >> code of course. > > This isn't feasible without different PCI IDs. At least on the host you can obviously differentiate them. >> Surely, you can argue that if they have different enough requirements th= ey >> should have different device IDs, but "different enough requirements" is= pretty >> vague and it's not under our control either. > > If you want two drivers in Linux you need two PCI IDs. > > We can't reliably select different drivers based on VFness because > VFness is wiped out during virtualization. Sure, but I thought the whole point is that some VFs are not given directly= to the VM, but have some kind of intermediate layer, such as vGPU. I.e. some k= ind of hybrid approach between full pass-through and mediated devices? >> But, if there is another solution for VFs already, e.g. in the case of n= ova-core >> vGPU, why restrict drivers from opt-out of VFs. (In a previous reply I m= entioned >> I prefer opt-in, but you convinced me that it should rather be >> opt-out.) > > I think nova-core has a temporary (OOT even!) issue that should be > resolved - that doesn't justify adding core kernel infrastructure that > will encourage more drivers to go away from our kernel design goals of > drivers working equally in host and VM. My understanding is that vGPU will ensure that the device exposed to the VM= will be set up to be (at least mostly) compatible with nova-core's PF code paths= ? So, there is a semantical difference between vGPU and nova-core that makes = a differentiation between VF and PF meaningful and justified. But maybe this understanding is not correct. If so, please educate me.