On 1/22/26 10:22 AM, Fiona Ebner wrote:
Am 22.01.26 um 10:05 AM schrieb Dominik Csapak:
On 1/21/26 5:26 PM, Fiona Ebner wrote:
Am 14.01.26 um 4:50 PM schrieb Dominik Csapak:
There are situations where a user might want to do extra things
for a passed through PCI device after it has been prepared/created (e.g.
in case of vGPU/mdev) but before the actual QEMU process is started.
Two examples are (both are used with NVIDIA vGPUs):
* setting 'vgpu_params' such as removing the frame-rate-limiter
* setting the gpu_instance_id for MIG devices
So instead of creating (nvidia-specific) interfaces for these, give a
user the ability to do it themselves via the hookscript as a first step.
How common are those use cases and how likely is it that such interfaces
will end up being implemented in the future? How likely is it that a
hookscript will be required for other stuff going forward? Just asking
for general evaluation :)
i'm still unsure if we should implement more vendor (in this case
nvidia) specific apis... on one hand, it would improve the ux
significantly for those who need it (though some use cases might be
rather narrow for e.g. the frame rate limiter), but otoh this
would introduce configs that we have to support "forever" (since
we might want to restore a backup that includes these configs,
even in future versions) and we basically have no control over
how these things work and if they even continue to exist...
i'd personally would lean to implement as little vendor
specific as possible, but maybe someone else has another argument...
as for how many things would require a hookscript in the future
is unclear, since i'm not clairvoyant ;)
but currently there are two things that would require it, and
one of those i'd lean to implement in our stack (MIGs, because
i guess it'll be a relatively common use case), the other one
(setting vgpu_params) is much more niche.
having a phase at that point in the hookscript with the
pciids/uuid would make future additions much easier though
without having us to do anything.
so, no straight forward answer here. sorry
That's perfectly fine. Thank you for elaborating!
if ($d->{mdev} || $d->{nvidia}) {
warn $@ if $@;
$chosen_mdev = $info;
- last if $chosen_mdev; # if successful, we're done
+ if (defined($chosen_mdev)) {
+ my $params = [$id, $chosen_mdev->{uuid} //
$chosen_mdev->{name}];
Having two semantically different arguments in the same place can be
rather confusing. Can we always put the name/pciid and just append the
uuid as an additional parameter if present to avoid this? Or
alternatively, have one param be the type, i.e. 'pciid' or 'uuid' and
the next param be the value. What do you think?
yes, good call. i'd simply always give the pciid (in case of mdevs of
the underlying device) and the uuid if it's there.
question is if that is future-proof, since in case we'd need to give an
additional parameter, but have no uuid, how could we call the hookscript
int that case?
so maybe the type approach is better?
do you have a preference?
Thinking about this again, I don't like my 'type' suggestion after all
as it would become messy very quickly if more params pop up in the
future. For the backup hook scripts, we pass parameters via the
environment and maybe that's the best approach here too? It's
future-proof and we get nice key-value pairing for free.
yeah, can make sense, i take a look how that would look like here, thanks!
_______________________________________________
pve-devel mailing list
[email protected]
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
