From: Dominik Csapak <d.csapak@proxmox.com>
To: Elias Huhsovitz <e.huhsovitz@proxmox.com>, pve-devel@lists.proxmox.com
Subject: Re: [PATCH docs v4 7/7] examples: add new hookscript phase to example hookscript
Date: Fri, 4 Sep 2026 13:51:43 +0200 [thread overview]
Message-ID: <b7325270-a19f-4497-9af3-6d9724e207bc@proxmox.com> (raw)
In-Reply-To: <DL5JQ1RLZQE3.1DTHCP5D65TJ@proxmox.com>
On 9/3/26 10:41 AM, Elias Huhsovitz wrote:
> Comments inline.
>
> On Tue Aug 25, 2026 at 3:54 PM CEST, Dominik Csapak wrote:
>> qemu-server has a new phase 'post-pci-prepare' that is called for vms
>> with pci passthrough for each device prepared.
>>
>> add that to the example hookscript and explain when it's called and its
>> parameters with a comment.
>>
>> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
>> ---
>> examples/guest-example-hookscript.pl | 29 ++++++++++++++++++++++++++++
>> 1 file changed, 29 insertions(+)
>>
>> diff --git a/examples/guest-example-hookscript.pl b/examples/guest-example-hookscript.pl
>> index 1cce2e3..02e7e7d 100755
>> --- a/examples/guest-example-hookscript.pl
>> +++ b/examples/guest-example-hookscript.pl
>> @@ -31,6 +31,35 @@ if ($phase eq 'pre-start') {
>> # print "preparations failed, aborting."
>> # exit(1);
>>
>> +} elsif ($phase eq 'post-pci-prepare') {
>
> The example hookscript ends with
>
> else {
> die "got unknown phase '$phase'\n";
> }
>
> Adding this new phase would then result in a breaking change.
> Current hookscripts do not check for 'post-pci-prepare', falling back to
> the else branch causing --> die "got unknown phase '$phase'\n";
>
> So all vms using a passed-thorugh GPU would have to update their hookscript to respect
> the new phase in order to avoid dying.
>
> I suggest 3 ways of handling this:
>
> A:
>
> Warn users in advance, so they are ready for the switch.
>
> B:
>
> Warn users in advance and change the
>
> do not die at the end of a hookscript, e.g.
>
> else {
> warn "got unknown phase '$phase'\n";
> }
>
> (altough this might defeat the purpose of using $stop_on_error=1 when
> executing the hookscript)
>
> C:
>
> seperate hookscripts for each phase. You would have
> * pre-start.pl
> * post-pci-prepare.pl
> * post-start.pl
> * pre-stop.pl
> * post-stop.pl
>
> When no hookscript for a phase (e.g. post-pci-prepare) exists, the
> call to
>
> PVE::GuestHelpers::exec_hookscript($conf, $vmid, 'post-pci-prepare', 1, $params);
>
> is never made, treating them optional for each phase.
>
> Although this would introduce significant overhead for simple uses, it
> would resolve this issue in "cleaner" way IMHO.
>
>
> All 3 Options that came to mind are not very elegant. Is there some
> obvious solution that I am missing?
I'd personally argue that this
is fine as is, even if it breaks some vm starts (the admin instantly
notices that they have to adapt the hookscript)
There shouldn't be too many users with hookscripts and the number that
simply verbatim copied the example are (hopefully) also the minority...
Separate hookscripts seem overkill, especially we'd have to handle
the legacy case of a single hookscript anyway.
disarming the example (downgrade die to warn) makes sense IMO
but maybe @fiona has some more input on this.
>
>
>> +
>> + # Only called for virtual machines, not containers.
>> + #
>> + # This phase will be called for each pci device that is passed through,
>> + # after it was prepared by the Proxmox VE stack. In other words when either
>> + # * the mdev/vGPU was created
>> + # * the driver was changed to vfio-pci and the device was reset
>> + #
>> + # This phase can be useful to do additional preparation that the Proxmox VE
>> + # stack does not do, like setting vgpu_params for NVIDIA vGPU.
>> + #
>> + # This phase has 3 additional parameters (one optional) given via the environment:
>> +
>> + # the id from the config, e.g. 'hostpci0'
>> + my $hostpci_id = $ENV{PVE_HOOK_ID};
>> +
>> + # the pciid of the passed through device or the underlying device in case of an mdev/vGPU
>> + # e.g. '0000:01:00.0'
>> + my $pciid = $ENV{PVE_HOOK_PCIID};
>> +
>> + # the uuid of the mediated device if it was one,
>> + # e.g. '00000001-0000-0000-0000-000000008006'
>> + # This is not set if the pci device is not an mdev.
>> + my $mdev_uuid = $ENV{PVE_HOOK_MDEV_UUID};
>> +
>> + print "Prepared PCI device for $hostpci_id with pciid: $pciid.\n";
>> + print "It is a mediated device with UUID: $mdev_uuid\n" if $mdev_uuid;
>> +
>> } elsif ($phase eq 'post-start') {
>>
>> # Second phase 'post-start' will be executed after the guest
>
next prev parent reply other threads:[~2026-09-04 11:51 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 13:54 [PATCH docs/guest-common/qemu-server v4 0/7] add new pci passthrough specific hookscript phase Dominik Csapak
2026-08-25 13:54 ` [PATCH guest-common v4 1/7] helpers: exec hookscript: add optional parameters Dominik Csapak
2026-09-03 8:40 ` Elias Huhsovitz
2026-09-03 8:52 ` Jakob Klocker
2026-08-25 13:54 ` [PATCH qemu-server v4 2/7] pci: mdev preparation: always generate local uuid first Dominik Csapak
2026-08-25 13:54 ` [PATCH qemu-server v4 3/7] pci: nvidia vgpu: correct wrong comment about uuid Dominik Csapak
2026-08-25 13:54 ` [PATCH qemu-server v4 4/7] pci: factor 'prepare_pci_devices' out to PVE::QemuServer::PCI module Dominik Csapak
2026-09-03 8:53 ` Jakob Klocker
2026-09-04 11:47 ` Dominik Csapak
2026-08-25 13:54 ` [PATCH qemu-server v4 5/7] pci: preparation: mdev: only generate uuid once Dominik Csapak
2026-08-25 13:54 ` [PATCH qemu-server v4 6/7] pci: call hookscript for each prepared pci device Dominik Csapak
2026-09-03 8:41 ` Elias Huhsovitz
2026-08-25 13:54 ` [PATCH docs v4 7/7] examples: add new hookscript phase to example hookscript Dominik Csapak
2026-09-03 8:41 ` Elias Huhsovitz
2026-09-04 11:51 ` Dominik Csapak [this message]
2026-08-26 6:10 ` [PATCH docs/guest-common/qemu-server v4 0/7] add new pci passthrough specific hookscript phase Dominik Csapak
2026-09-03 8:54 ` Jakob Klocker
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=b7325270-a19f-4497-9af3-6d9724e207bc@proxmox.com \
--to=d.csapak@proxmox.com \
--cc=e.huhsovitz@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox