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 46B0CCCA476 for ; Tue, 7 Oct 2025 10:14:51 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E16EA10E370; Tue, 7 Oct 2025 10:14:50 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="coVJS50V"; dkim-atps=neutral Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0DDCA10E370 for ; Tue, 7 Oct 2025 10:14:50 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id C5F5D417A2; Tue, 7 Oct 2025 10:14:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 91C2CC4CEF1; Tue, 7 Oct 2025 10:14:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1759832089; bh=Ju8nRdH0aqsvJyBikVF6BTkTxsWPAUsD1kJPBH9jKMI=; h=Date:Subject:Cc:To:From:References:In-Reply-To:From; b=coVJS50VC5DdgdFrzMctuKfI1jM4biaLANzzCd6NZGDn2h+6DSADWSF5xTGb2Om6P 4ZlcxbeDB8Us2HWYQ9fzV96fbmcYuIDtHexC1rMhRax7Wnyjk1OO+/ztARKcDEpNN+ xX3J56OFoWZ80iGc4bqhDj/Gkn5YiCalk9EIarkYSMxC790kDET80jnVnNDk2f8fn2 /GRpcmRhxUUy68agWtK0rFr4UBiedswkMhz0GFmIUlQ9E8G4oBGpDpJ/KHgY/WBwAo Mp4llS+zLw8oVM7+n4+G8PM4kXFvPalhLBMcahKodaY3RPKCXnKoAhE4sJc2WaUesJ aUuRiolcXc/Xw== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 07 Oct 2025 12:14:42 +0200 Message-Id: Subject: Re: [PATCH 0/2] rust: pci: expose is_virtfn() and reject VFs in nova-core Cc: "Jason Gunthorpe" , "John Hubbard" , "Alexandre Courbot" , "Joel Fernandes" , "Timur Tabi" , "Alistair Popple" , "Surath Mitra" , "David Airlie" , "Simona Vetter" , "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" , "nouveau@lists.freedesktop.org" , "linux-pci@vger.kernel.org" , "rust-for-linux@vger.kernel.org" , "LKML" , "Alex Williamson" , "Neo Jia" To: "Zhi Wang" From: "Danilo Krummrich" References: <12076511-7113-4c53-83e8-92c5ea0eb125@nvidia.com> <5da095e6-040d-4531-91f9-cd3cf4f4c80d@nvidia.com> <20251001144814.GB3024065@nvidia.com> <20251002115851.GB3195801@nvidia.com> <20251002134221.GA3266220@nvidia.com> <0c94b94b-68a7-47e2-acde-0a2082ed36bf@nvidia.com> <20251002143116.GA3268803@nvidia.com> <75316915-fbae-487a-b710-ce01f088a2ed@nvidia.com> In-Reply-To: <75316915-fbae-487a-b710-ce01f088a2ed@nvidia.com> X-BeenThere: nouveau@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Nouveau development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nouveau-bounces@lists.freedesktop.org Sender: "Nouveau" On Tue Oct 7, 2025 at 8:51 AM CEST, Zhi Wang wrote: > From the device vendor=E2=80=99s perspective, we have no support or use c= ase for > a bare-metal VF model, not now and not in the foreseeable future. Who is we? I think there'd be a ton of users that do see such use-cases. What does "no support" mean? Are there technical limitation that prevent an implementation (I haven't seen any so far)? > Even > hypothetically, such support would not come from nova-core.ko, since > that would defeat the purpose of maintaining a trimmed-down kernel > module where minimizing the attack surface and preserving strict > security boundaries are primary design goals. I wouldn't say the *primary* design goal is to be as trimmed-down as possib= le. The primary design goals are rather proper firmware abstraction, addressing design incompatibilities with modern graphics and compute APIs, memory safe= ty concerns and general maintainability. It does make sense to not run the vGPU use-case on top of all the additiona= l DRM stuff that will go into nova-drm, since this is clearly not needed in the v= GPU use-case. But, it doesn't mean that we have to keep everything out of nova-= core for this purpose. I think the bare-metal VF model is a very interesting use-case and if it is technically feasable we should support it. And I think it should be in nova-core. The difference between nova-core running on a bare metal VF and nova-core running on the same VF in a VM shouldn't be that different anyway= s, no?