From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 2A1C29BA8F for ; Fri, 20 Oct 2023 09:51:45 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 0CEA631021 for ; Fri, 20 Oct 2023 09:51:45 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Fri, 20 Oct 2023 09:51:44 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id C166843543; Fri, 20 Oct 2023 09:51:43 +0200 (CEST) Message-ID: <82d37443-ca7f-4cf3-aae0-36444e4769af@proxmox.com> Date: Fri, 20 Oct 2023 09:51:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Proxmox VE development discussion , Wolfgang Bumiller , Filip Schauer References: <20231019121856.379185-1-f.schauer@proxmox.com> From: Dominik Csapak In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.012 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH RFC container] Add device passthrough X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2023 07:51:45 -0000 On 10/20/23 09:08, Wolfgang Bumiller wrote: > On Thu, Oct 19, 2023 at 02:18:56PM +0200, Filip Schauer wrote: >> Signed-off-by: Filip Schauer >> --- >> Is it reasonable to add a "dev[n]" argument to the pct.conf, given that >> device mount points only allow passing through block devices? > > Why would they only allow block devices? > > Also, Dominik recently added resource mappings for qemu for USB & PCI. > PCI might be tricky, but for USB we may be able to use these mappings as > well. > That said, "raw" `/dev` node pass-through still makes sense as a > separate thing for containers anyway since raw `lxc....` entries in the > container config can currently be very inconvenient to deal with > particularly with unprivileged containers (read on below for why...) just to chime in here, i don't think it'll be easily possible to reuse the pci/usb maps as is since we'd have to map from pciid /usb-vendor/device (or path) to a device node? i don't think thats generally possible, since the driver does not always make that info easily available (e.g. multi gpu setup and /dev/dri/cardX, or usb-to-serial adapters and /dev/ttySX ?) i guess it could work, but we probably would have to implement that for every driver out there? what i would like to see however is to integrate a new type of mapping for container devices specifically so that the ux is the same (create mappings for whole cluster, assigning privileges, etc) we still can provide a 'raw' mechanic as well for those who only ever use root@pam on a single node, but I'd not be against only using mappings either