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
Call it for each prepared device, so that we can give the hookscript the
'hostpciX' id, and the used uuid (in case of mdevs) or the pci id (in
case of regular or modern vGPU passthrough).
Include the generated mdev uuid in the return value of
`prepare_pci_device`, to avoid having to generate that multiple times.
With that we can get rid of one extra generation here too.
Signed-off-by: Dominik Csapak <[email protected]>
---
src/PVE/QemuServer.pm | 18 +++++++++++++++---
src/PVE/QemuServer/PCI.pm | 1 +
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/src/PVE/QemuServer.pm b/src/PVE/QemuServer.pm
index 9d2cf44d..a676c9f4 100644
--- a/src/PVE/QemuServer.pm
+++ b/src/PVE/QemuServer.pm
@@ -5632,10 +5632,23 @@ sub vm_start_nolock {
Could you factor out the loop for activation here as a new
PVE::QemuServer::PCI::prepare_pci_devices() helper (notice the plural)?
Because vm_start_nolock() could use a bit of a diet.
sure, will do in the v2
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?
+ PVE::GuestHelpers::exec_hookscript(
+ $conf, $vmid, 'post-pci-prepare', 1, $params,
+ );
+ last;
+ }
} else {
die $@ if $@;
+ if (defined($info)) {
+ my $params = [$id, $info->{name}];
+ PVE::GuestHelpers::exec_hookscript(
+ $conf, $vmid, 'post-pci-prepare', 1, $params,
+ );
+ }
}
+
}
next if !$d->{mdev} && !$d->{nvidia};
@@ -5647,8 +5660,7 @@ sub vm_start_nolock {
my $smbios_conf = parse_smbios1($conf->{smbios1});
$uuid = $smbios_conf->{uuid} if
defined($smbios_conf->{uuid});
}
- $uuid = PVE::QemuServer::PCI::generate_mdev_uuid($vmid, $index)
- if !defined($uuid);
+ $uuid = $chosen_mdev->{uuid} if !defined($uuid);
}
}
push @$cmd, '-uuid', $uuid if defined($uuid);
diff --git a/src/PVE/QemuServer/PCI.pm b/src/PVE/QemuServer/PCI.pm
index c9cf8de0..9603f5ea 100644
--- a/src/PVE/QemuServer/PCI.pm
+++ b/src/PVE/QemuServer/PCI.pm
@@ -750,6 +750,7 @@ sub prepare_pci_device {
} elsif (my $mdev = $device->{mdev}) {
my $uuid = generate_mdev_uuid($vmid, $index);
PVE::SysFSTools::pci_create_mdev_device($pciid, $uuid, $mdev);
+ $info->{uuid} = $uuid;
} else {
die "can't unbind/bind PCI group to VFIO '$pciid'\n"
if !PVE::SysFSTools::pci_dev_group_bind_to_vfio($pciid);
_______________________________________________
pve-devel mailing list
[email protected]
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
