[pve-devel] [PATCH common 4/4] sysfs: use new PVE::RS::VFIO::Nvidia module to retrieve vGPU info
Dominik Csapak
d.csapak at proxmox.com
Wed Jan 21 09:08:45 CET 2026
On 1/20/26 4:00 PM, Thomas Lamprecht wrote:
> Am 20.01.26 um 14:12 schrieb Christoph Heiss:
>> pci_dev_physfn_id() is used to obtain the parent device of a virtual
>> function, i.e. the physical function.
>>
>> Needed for retrieving information about Nvidia vGPU devices via
>> proxmox-ve-vfio, as libnvidia-ml functions only work with physical
>> functions.
>>
>> Signed-off-by: Christoph Heiss <c.heiss at proxmox.com>
>> ---
>> src/PVE/SysFSTools.pm | 45 ++++++++++++++++++++++++++++++-------------
>> 1 file changed, 32 insertions(+), 13 deletions(-)
>>
>> diff --git a/src/PVE/SysFSTools.pm b/src/PVE/SysFSTools.pm
>> index a00fbcb..89e57b9 100644
>> --- a/src/PVE/SysFSTools.pm
>> +++ b/src/PVE/SysFSTools.pm
>> @@ -4,8 +4,10 @@ use strict;
>> use warnings;
>>
>> use IO::File;
>> +use File::Basename;
>>
>> use PVE::Tools qw(file_read_firstline dir_glob_foreach);
>> +use PVE::RS::VFIO::Nvidia;
>
> we do not depend on libpve-rs-perl in libpve-common-perl, and if easily possible
> I'd strongly favor keeping it that way, bootstrapping and handling bigger package
> bumps with newer versioned dependencies or break/depends bumps is already quite
> a bit of work as is, such stuff does not make it easier, especially if adding
> a new dependencies is not recorded in d/control's packaging definition.
>
> Can this move to some non-leaf package instead? Where are the users of this, only
> qemu-server or other too (pve-manager?)?
>
>
hmm.. as far as i can see it, we need to use that module in sysfstools
where we get info about mdevs. This is used in qemu-server
and (currently) pve-manager
If we don't want to have that dep here, we have IMO the following
possiblities:
* split the relevant part out (e.g. into qemu-server, still reachable
from pve-manager).
* move the whole of sysfstools somewhere else
this is needed in guest-common, pve-manager and qemu-server,
so imho guest-common would be the next best place?
though we could also create a seperate package for that too.
Note that pve-storage still includes PVE::SysFSTools, but does not
actually need it anymore, so we should remove it there anyway
Advantage of the second method (though more work) would be to make
pve-common smaller.
We could also think about producing more than one debian package from
pve-common, similar to how we do it with the 'proxmox' rust crate,
not sure how practical that is though.
In summary I think simply moving the mdev/vgpu stuff to qemu-server
makes the most sense for now.
More information about the pve-devel
mailing list