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) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id D46A49E347 for ; Tue, 31 Oct 2023 10:01:17 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id B263818618 for ; Tue, 31 Oct 2023 10:00:47 +0100 (CET) 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) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Tue, 31 Oct 2023 10:00:46 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 7215A42CE3 for ; Tue, 31 Oct 2023 10:00:46 +0100 (CET) Message-ID: <95f912b4-25b8-403e-8112-50ce689cf21a@proxmox.com> Date: Tue, 31 Oct 2023 10:00:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-GB To: Proxmox VE development discussion , Wolfgang Bumiller , Filip Schauer References: <20231024125554.131800-1-f.schauer@proxmox.com> <20231024125554.131800-3-f.schauer@proxmox.com> From: Thomas Lamprecht In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.069 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 T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [PATCH v2 guest-common 1/1] Add foreach_passthrough_device 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: Tue, 31 Oct 2023 09:01:17 -0000 On 30/10/2023 14:12, Wolfgang Bumiller wrote: > On Tue, Oct 24, 2023 at 02:55:54PM +0200, Filip Schauer wrote: >> + >> + $func->($key, "dev/bus/usb/$bus_id/$device_id", @param); > > So this will do... something :-) > But unfortunately it won't deal with the *interesting* bits. > > So while I do like the idea of having such mappings, for it to make > sense we'd also need to figure out the device specific nodes. > Eg. for input devices we'd want to include `/dev/input/eventXY`, for eg. > FIDO keys we'd want `/dev/hidraw*` devices. > > I'm not sure how much work we should put into this in the initial > implementation, the question is mainly whether we want to do it like > *this* in the first place and how much we plan to support. Hmm, yeah, let's leave the USB mappings out for now, not really winning much here. > > Or maybe it would make more sense to have specific entries for hidraw, > event devices, block devices, ... instead? > I'm not sure. A device (node) mapping with a sub-type like block ("disk") devices might be indeed better then, as that could be re-used for VMs too, e.g., for passing through a /dev/sda (well, more likely via /dev/disk/by-id/...) device through. IIUC, that would be also more in line with Dominik's feedback. In any way, let's get raw pass-through right first, adding in mappings should be doable then, we added them only much later for VMs too, so I'd think one would have to actively try to really make that hard to do in the future here.