public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: "Elias Huhsovitz" <e.huhsovitz@proxmox.com>
To: "Dominik Csapak" <d.csapak@proxmox.com>, <pve-devel@lists.proxmox.com>
Subject: Re: [PATCH docs v4 7/7] examples: add new hookscript phase to example hookscript
Date: Thu, 03 Sep 2026 10:41:59 +0200	[thread overview]
Message-ID: <DL5JQ1RLZQE3.1DTHCP5D65TJ@proxmox.com> (raw)
In-Reply-To: <20260825135502.3971930-8-d.csapak@proxmox.com>

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?


> +
> +    # 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





  reply	other threads:[~2026-09-03  8:42 UTC|newest]

Thread overview: 15+ 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-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 [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=DL5JQ1RLZQE3.1DTHCP5D65TJ@proxmox.com \
    --to=e.huhsovitz@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal