From: Fiona Ebner <f.ebner@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Dominik Csapak <d.csapak@proxmox.com>
Subject: Re: [pve-devel] [PATCH qemu-server 1/1] pci: call hookscript for each prepared pci device
Date: Wed, 21 Jan 2026 17:27:39 +0100 [thread overview]
Message-ID: <3517f917-0532-4420-bd53-1890a6959ef1@proxmox.com> (raw)
In-Reply-To: <20260114155043.3313473-3-d.csapak@proxmox.com>
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 :)
> 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 <d.csapak@proxmox.com>
> ---
> 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.
> 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?
> + 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
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2026-01-21 16:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-14 15:50 [pve-devel] [PATCH docs/guest-common/qemu-server 0/3] add new pci passthrough specific hookscript phase Dominik Csapak
2026-01-14 15:50 ` [pve-devel] [PATCH guest-common 1/1] helpers: exec hookscript: add optional parameters Dominik Csapak
2026-01-14 15:50 ` [pve-devel] [PATCH qemu-server 1/1] pci: call hookscript for each prepared pci device Dominik Csapak
2026-01-21 16:27 ` Fiona Ebner [this message]
2026-01-14 15:50 ` [pve-devel] [PATCH docs 1/1] examples: add new hookscript phase to example hookscript Dominik Csapak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3517f917-0532-4420-bd53-1890a6959ef1@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=d.csapak@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.