From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <f.schauer@proxmox.com> 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 B3D719C71E for <pve-devel@lists.proxmox.com>; Tue, 24 Oct 2023 15:00:43 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 8E84C85AD for <pve-devel@lists.proxmox.com>; Tue, 24 Oct 2023 15:00:13 +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 <pve-devel@lists.proxmox.com>; Tue, 24 Oct 2023 15:00:10 +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 73BCB44B7B for <pve-devel@lists.proxmox.com>; Tue, 24 Oct 2023 15:00:09 +0200 (CEST) Message-ID: <47130fdb-2f51-afbe-8e5d-103a7ae6b838@proxmox.com> Date: Tue, 24 Oct 2023 15:00:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 To: Dominik Csapak <d.csapak@proxmox.com>, Thomas Lamprecht <t.lamprecht@proxmox.com>, Proxmox VE development discussion <pve-devel@lists.proxmox.com>, Wolfgang Bumiller <w.bumiller@proxmox.com> References: <20231019121856.379185-1-f.schauer@proxmox.com> <elrza7dys6b4gjlppamlx2jb5rudcheykscqhhq4hep54tmigd@llzl6w6rmtqs> <82d37443-ca7f-4cf3-aae0-36444e4769af@proxmox.com> <54225ac2-b494-4c11-9150-1ad647a65eaf@proxmox.com> <61041ddd-5475-48fd-a7ef-d1816bed25a2@proxmox.com> Content-Language: en-US From: Filip Schauer <f.schauer@proxmox.com> In-Reply-To: <61041ddd-5475-48fd-a7ef-d1816bed25a2@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 1.474 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 NICE_REPLY_A -3.339 Looks like a legit reply (A) 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 <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Tue, 24 Oct 2023 13:00:43 -0000 A patch v2 is available: https://lists.proxmox.com/pipermail/pve-devel/2023-October/059617.html On 20/10/2023 10:39, Dominik Csapak wrote: > On 10/20/23 10:29, Thomas Lamprecht wrote: >> Am 20/10/2023 um 09:51 schrieb Dominik Csapak: >>> On 10/20/23 09:08, Wolfgang Bumiller wrote: >>>> 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? >>> >> >> USB should be workable via resolving to /dev/bus/usb/*, PCI could be, >> theoretically, but isn't now and probably won't be anytime soon – i.e., >> as Wolfgang mentioned off list, there's a reason that there's no >> /dev/bus/pci/ >> >>> 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) >> >> I'd try hard to re-use the USB mappings, those seem to be one of the >> most common pass-through setups for containers (e.g., for those >> home automation zigbee/matter/... adapters, or in some countries DVB-T >> ones, be it for TV or ADS-B plane tracking). > > i guess, but sadly the /dev/bus/usb endpoint is mostly not what you want > to pass-through but the driver specific /dev/ttySX /dev/dvb/X and so on > (there are situations where the /dev/bus/usb path is the wanted one, > but there are many where it isn't) > > and while we can map from those to the usb device/vendor/path the reverse > mapping is not so easy (at least when i tried i did not found a > generic way > via udev or similar > > i would welcome it though if there is a way to do that of course > >> >> If we can make USB work then we'd have the basic concept of attaching >> a mapping done, adding a new type of (block/char) device mapping could >> then be an independent task for later to keep scope a bit smaller. >> >> Fixing Wolfgang's comments for workable pass-through for unprivileged >> containers is probably the most important change needed for now. >> >> I'd then even be open to apply this with (root@pam only!) absolute >> path to /dev support only, but IMO resolving the mapping itself should >> not be too hard, so if using /dev/bus/usb/ works having that in there >> from the start would be definitively nice. > >