Re: [pve-devel] [PATCH common 4/4] sysfs: use new PVE::RS::VFIO::Nvidia module to retrieve vGPU info

[Dominik Csapak <d.csapak@proxmox.com>]

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


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel