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 01D4D2EC08E; Thu, 2 Oct 2025 13:03:45 +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=1759410226; cv=none; b=BjGdS+zxpQvtXSh6Gwy4t3s9ZkoYv7GmAOGyVH7x6TJmhlES3wAC9m0fX34WppLVBwppe2yHHvYVLD1jS7lwisrBzlFWU0QBtYkqiskfepqHJL4FsDjEWzwEohBRQYeqvJMtLQqQIIheFeczM5nNC7hN+DUNaw7fY6606Xxm96Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759410226; c=relaxed/simple; bh=IqmZ2qn3/cwmHXiV+sDN9KZgmACU1tPIoXsK0UdOIVg=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:Cc:To:From: References:In-Reply-To; b=cLSgjTFc5GXzWuc9Txcdm4Wy++L5S7r4nwa0z6lKw4oTMMoNBMF2NSAcOrBVadWwLso39jgvWxD5uxv1uEpsPsMzZiiwzE4UeBLtgHxnc0fZML+rCdeZV7o6lM6nbRLwB1ayRSfeQtnMEaieEQ444dP0xhGNzanyUA7NVGRa/ZY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tK7L357z; 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="tK7L357z" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9F94CC4CEF4; Thu, 2 Oct 2025 13:03:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1759410225; bh=IqmZ2qn3/cwmHXiV+sDN9KZgmACU1tPIoXsK0UdOIVg=; h=Date:Subject:Cc:To:From:References:In-Reply-To:From; b=tK7L357zNRoAygiOUdtULi+T8umVIFJxKaXPxAvPO/y5yIv7YNhM7mm/9ecDNViJb U5c24LtvIkzzXU+wyIYZgyR/Knb1Xc4rQwmfSTb/wFwN1Ajm0X+7zIrvoVscLgOvwI R+qaC+Azn3dYLZPyQ3Tt1bb/psBFOV7wzGXRwSLEf07icqaRWz6NEh1KEEjh+WLYYa As1LaqL6oWluc9DUTl41JaWPxewctI23uLEHtcXblAPrJLxovJU+LP6w8jlxDKRsaR 0BHN0wN9fMYudk6kEeNyDQnTDi7/CbM75I63QgKiyWR9/FZXYd5kV+ePZkxuGHqGQB iL9XYmmt+fE4g== Precedence: bulk X-Mailing-List: rust-for-linux@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 15:03:38 +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> In-Reply-To: <20251002123921.GG3195801@nvidia.com> On Thu Oct 2, 2025 at 2:39 PM CEST, Jason Gunthorpe wrote: > On Thu, Oct 02, 2025 at 02:18:36PM +0200, Danilo Krummrich wrote: >> On Thu Oct 2, 2025 at 2:11 PM CEST, Jason Gunthorpe wrote: >> > On Wed, Oct 01, 2025 at 07:00:09PM -0700, John Hubbard wrote: >> >> Add a "supports_vf" flag to struct pci_driver to let drivers declare >> >> Virtual Function (VF) support. If a driver does not support VFs, then >> >> the PCI driver core will not probe() any VFs for that driver's device= s. >> >>=20 >> >> On the Rust side, add a const "SUPPORTS_VF" Driver trait, defaulting = to >> >> false: drivers must explicitly opt into VF support. >> > >> > As I said in the other thread - please no. >> > >> > Linux drivers are expected to run on their VFs. >>=20 >> The consequence would be that drivers for HW that can export VFs would n= eed to >> be rejected upstream if they only support the PF, but no VFs. IMHO, that= 's an >> unreasonable requirement. > > Not rejected, they just need to open code a simple isvf check and fail > during probe if they really have a (hopefully temporary) problem. The question is whether it is due to a (temporary) problem, or if it is by design. I think it's not unreasonable to have a driver for the PF and a separate dr= iver for the VFs if they are different enough; the drivers can still share commo= n code of course. Surely, you can argue that if they have different enough requirements they should have different device IDs, but "different enough requirements" is pr= etty vague and it's not under our control either. > This not really a realistic case. Linux running in the VM *should* > have drivers that operate the VF, and those existing drivers *should* > work in the PF context. > > Drivers that work in VM but not in a host should not be encouraged!! I agree, we should indeed encourage HW manufacturers to design the HW in a = way that a single driver works in both cases, i.e. less less code to maintain, = less surface for bugs, etc., if that is what you mean. But, if there is another solution for VFs already, e.g. in the case of nova= -core vGPU, why restrict drivers from opt-out of VFs. (In a previous reply I ment= ioned I prefer opt-in, but you convinced me that it should rather be opt-out.) > AFAICT this is even true for novacore, the driver should "work" but > the VF won't be provisioned today so it should fail startup in some > way. eg "no vram" or something like that. > >> > This temporary >> > weirdness of novacore should not be elevated to a core behavior that >> > people will misuse. >>=20 >> It's not just nova-core, please see [1]. >>=20 >> [1] https://lore.kernel.org/lkml/DD7TP31FEE92.2E0AKAHUOHVVF@kernel.org/ > > I responded there, I don't think the reasons those were added to ICE > and then cargo-culted are very good, not good enough to justify adding > it to the core code. Indeed, the justification of ICE is clearly wrong.