From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 9B12C1FF15E for ; Wed, 21 Jan 2026 17:27:56 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id CE0494460; Wed, 21 Jan 2026 17:28:12 +0100 (CET) Message-ID: <3517f917-0532-4420-bd53-1890a6959ef1@proxmox.com> Date: Wed, 21 Jan 2026 17:27:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Proxmox VE development discussion , Dominik Csapak References: <20260114155043.3313473-1-d.csapak@proxmox.com> <20260114155043.3313473-3-d.csapak@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: <20260114155043.3313473-3-d.csapak@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1769012802739 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.017 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [qemuserver.pm, pci.pm] Subject: Re: [pve-devel] [PATCH qemu-server 1/1] pci: call hookscript for each prepared pci device X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" 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 > --- > 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