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 F146B1FF145 for ; Thu, 22 Jan 2026 10:06:24 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 33CA110F0E; Thu, 22 Jan 2026 10:06:42 +0100 (CET) Message-ID: <59ce35fc-4557-465b-8897-2074818618ec@proxmox.com> Date: Thu, 22 Jan 2026 10:06:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta To: Fiona Ebner , Proxmox VE development discussion References: <20260114155043.3313473-1-d.csapak@proxmox.com> <20260114155043.3313473-3-d.csapak@proxmox.com> <3517f917-0532-4420-bd53-1890a6959ef1@proxmox.com> Content-Language: en-US From: Dominik Csapak In-Reply-To: <3517f917-0532-4420-bd53-1890a6959ef1@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1769072740595 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.030 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 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" 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 >> --- >> 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 pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel