From: Dominik Csapak <d.csapak@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Wolfgang Bumiller <w.bumiller@proxmox.com>,
Filip Schauer <f.schauer@proxmox.com>
Subject: Re: [pve-devel] [PATCH RFC container] Add device passthrough
Date: Fri, 20 Oct 2023 10:39:06 +0200 [thread overview]
Message-ID: <61041ddd-5475-48fd-a7ef-d1816bed25a2@proxmox.com> (raw)
In-Reply-To: <54225ac2-b494-4c11-9150-1ad647a65eaf@proxmox.com>
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.
next prev parent reply other threads:[~2023-10-20 8:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-19 12:18 Filip Schauer
2023-10-20 7:08 ` Wolfgang Bumiller
2023-10-20 7:51 ` Dominik Csapak
2023-10-20 8:29 ` Thomas Lamprecht
2023-10-20 8:39 ` Dominik Csapak [this message]
2023-10-24 13:00 ` Filip Schauer
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=61041ddd-5475-48fd-a7ef-d1816bed25a2@proxmox.com \
--to=d.csapak@proxmox.com \
--cc=f.schauer@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=t.lamprecht@proxmox.com \
--cc=w.bumiller@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