[pve-devel] [PATCH RFC container] Add device passthrough

[Filip Schauer]

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 at 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.
>
>