From: Wolfgang Bumiller <w.bumiller@proxmox.com>
To: Filip Schauer <f.schauer@proxmox.com>
Cc: pve-devel@lists.proxmox.com
Subject: Re: [pve-devel] [PATCH v2 guest-common 1/1] Add foreach_passthrough_device
Date: Mon, 30 Oct 2023 14:12:09 +0100 [thread overview]
Message-ID: <ftprf2og5egdffjj5wb3hgipyugzdj6dixnc2hzxcdeihxkgg3@jchycj3kudvs> (raw)
In-Reply-To: <20231024125554.131800-3-f.schauer@proxmox.com>
On Tue, Oct 24, 2023 at 02:55:54PM +0200, Filip Schauer wrote:
> Add a function to iterate over passthrough devices of a provided
> container config.
As container specific code this should be in pve-container.
>
> Signed-off-by: Filip Schauer <f.schauer@proxmox.com>
> ---
> src/PVE/AbstractConfig.pm | 44 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
>
> diff --git a/src/PVE/AbstractConfig.pm b/src/PVE/AbstractConfig.pm
> index a286b13..ed26e91 100644
> --- a/src/PVE/AbstractConfig.pm
> +++ b/src/PVE/AbstractConfig.pm
> @@ -484,6 +484,50 @@ sub foreach_volume {
> return $class->foreach_volume_full($conf, undef, $func, @param);
> }
>
> +sub foreach_passthrough_device {
> + my ($class, $conf, $func, @param) = @_;
> +
> + foreach my $key (keys %$conf) {
> + next if $key !~ m/^dev(\d+)$/;
> +
> + my $device = $class->parse_device($conf->{$key});
(`parse_device` does not exist in AbstractConfig)
> +
> + if (defined($device->{path})) {
> + die "Device path $device->{path} does not start with /dev/\n"
> + if $device->{path} !~ m!^/dev/!;
IMO `parse_device()` should be responsible for the above check, and
`verify_lxc_dev_string()` already does this, so the above check can just
be dropped.
> +
> + my $sanitized_path = substr($conf->{$key}, 1);
> + die "Device /$sanitized_path does not exist\n" unless (-e "/$sanitized_path");
Since we now have a property string and `parse_device()`, it would make
more sense to pass `$device` rather than this path.
In fact, thinking about this more I'm not sure passing the substring
through was the best idea, since it's rather specific to how it'll end
up in the lxc config. That's my bad.
> +
> + $func->($key, $sanitized_path, @param);
> + } elsif (defined($device->{usbmapping})) {
> + my $mapping = $device->{usbmapping};
> + my $map_devices = PVE::Mapping::USB::find_on_current_node($mapping);
> +
> + die "USB device mapping not found for '$mapping'\n"
> + if !$map_devices || !scalar($map_devices->@*);
> +
> + die "More than one USB mapping per host not supported\n"
> + if scalar($map_devices->@*) > 1;
> +
> + eval {
> + PVE::Mapping::USB::assert_valid($mapping, $map_devices->[0]);
> + };
> + if (my $err = $@) {
> + die "USB Mapping invalid (hardware probably changed): $err\n";
> + }
> +
> + my $map_device = $map_devices->[0];
> + my $lsusb_output = `/usr/bin/lsusb -d $map_device->{id}`;
> + my ($bus_id, $device_id) = $lsusb_output =~ /Bus (\d+) Device (\d+)/;
^ qx/backticks should be avoided, it'll be interpreted by a shell
Also, we don't need this :-)
See `PVE::SysFSTools::scan_usb()` which does essentially the same thing
without invoking an external binary.
> +
> + $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.
Or maybe it would make more sense to have specific entries for hidraw,
event devices, block devices, ... instead?
I'm not sure.
> + } else {
> + die "Either path or usbmapping has to be defined for $key";
> + }
> + }
> +}
> +
> # $volume_map is a hash of 'old_volid' => 'new_volid' pairs.
> # This method replaces 'old_volid' by 'new_volid' throughout the config including snapshots, pending
> # changes, unused volumes and vmstate volumes.
> --
> 2.39.2
next prev parent reply other threads:[~2023-10-30 13:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-24 12:55 [pve-devel] [PATCH many v2] Add container device passthrough Filip Schauer
2023-10-24 12:55 ` [pve-devel] [PATCH v2 container 1/1] Add " Filip Schauer
2023-10-30 13:34 ` Wolfgang Bumiller
2023-11-02 14:28 ` Filip Schauer
2023-11-03 8:14 ` Wolfgang Bumiller
2023-11-07 13:49 ` Filip Schauer
2023-10-24 12:55 ` [pve-devel] [PATCH v2 guest-common 1/1] Add foreach_passthrough_device Filip Schauer
2023-10-30 13:12 ` Wolfgang Bumiller [this message]
2023-10-31 9:00 ` Thomas Lamprecht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ftprf2og5egdffjj5wb3hgipyugzdj6dixnc2hzxcdeihxkgg3@jchycj3kudvs \
--to=w.bumiller@proxmox.com \
--cc=f.schauer@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox