From: Thomas Lamprecht <t.lamprecht@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 2/3] pci: add helpers to (un)reserve pciids for a vm
Date: Tue, 5 Oct 2021 16:13:07 +0200 [thread overview]
Message-ID: <90c1f81e-6cc0-36ce-9e84-d72ad7e7b578@proxmox.com> (raw)
In-Reply-To: <20211005131200.791836-3-d.csapak@proxmox.com>
On 05.10.21 15:11, Dominik Csapak wrote:
> saves a list of pciid <-> vmid mappings in /var/run
> that we can check when we start a vm
a few style nits but also one serious note inline
>
> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
> ---
> PVE/QemuServer/PCI.pm | 89 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 89 insertions(+)
>
> diff --git a/PVE/QemuServer/PCI.pm b/PVE/QemuServer/PCI.pm
> index 5608207..0626b76 100644
> --- a/PVE/QemuServer/PCI.pm
> +++ b/PVE/QemuServer/PCI.pm
> @@ -5,6 +5,7 @@ use strict;
>
> use PVE::JSONSchema;
> use PVE::SysFSTools;
> +use PVE::Tools;
>
> use base 'Exporter';
>
> @@ -461,4 +462,92 @@ sub print_hostpci_devices {
> return ($kvm_off, $gpu_passthrough, $legacy_igd);
> }
>
> +my $PCIID_RESERVATION_FILE = "/var/run/pve-reserved-pciids";
> +my $PCIID_RESERVATION_LCK = "/var/lock/pve-reserved-pciids.lck";
> +
> +my $parse_pci_reservation = sub {
> + my $pciids = {};
> +
> + if (my $fh = IO::File->new ($PCIID_RESERVATION_FILE, "r")) {
> + while (my $line = <$fh>) {
> + if ($line =~ m/^($PCIRE)\s(\d+)\s(\d+)$/) {
> + $pciids->{$1} = {
> + timestamp => $2,
> + vmid => $3,
> + };
> + }
> + }
> + }
> +
> + return $pciids;
> +};
> +
> +my $write_pci_reservation = sub {
> + my ($pciids) = @_;
> +
> + my $data = "";
> + foreach my $p (keys %$pciids) {
prefer for over foreach
> + $data .= "$p $pciids->{$p}->{timestamp} $pciids->{$p}->{vmid}\n";
> + }
my $data = join("\n", map { "$_ $pciids->{$_}->{timestamp} $pciids->{$_}->{vmid}" }, keys $pciids->%*);
> +
> + PVE::Tools::file_set_contents($PCIID_RESERVATION_FILE, $data);
> +};
> +
> +sub remove_pci_reservation {
> + my ($id) = @_;
> +
> + my $code = sub {
> + my $pciids = $parse_pci_reservation->();
> +
> + delete $pciids->{$id};
> +
> + $write_pci_reservation->($pciids);
> + };
> +
> + PVE::Tools::lock_file($PCIID_RESERVATION_LCK, 10, $code);
IMO it has some benefit for passing the closure directly, less lines and slightly
more obvious about the locking (as at least I read methods from top to bottom):
PVE::Tools::lock_file($PCIID_RESERVATION_LCK, 10, sub {
my $pciids = $parse_pci_reservation->();
...
});
but we have no clear style guide regarding this and def. use both variants, so no
hard feelings here.
> + die $@ if $@;
> +
> + return;
> +}
> +
> +sub reserve_pci_usage {
> + my ($id, $vmid) = @_;
> +
> + my $code = sub {
> +
> + # have a 60 second grace period, since we reserve before
> + # we actually start the vm
huh, whats the use on that? so I can "steal" PCI devices the first 60s, feels weird...
Why not either:
* catch any start error somewhere centrally and clear the reservation in that
case again, a kill/crash could still result into false-positives though
* save timestamp now and then once we know it the PID of the VM as third
param, VMID + PID are quite good in being resistent against PID-reuse
and an future start could check if the process still lives to decide
if the reservation is still valid
> + my $graceperiod = 60;
> + my $ctime = time();
> +
> + my $pciids = $parse_pci_reservation->();
> +
> + if (my $pciid = $pciids->{$id}) {
> + if ($pciid->{vmid} == $vmid) {
> + return; # already reserved
> + }
I'd prefer a onliner for above, less lines/noise while not yet being
code-golfy, so easier to read IMO. i.e.:
return if $pciid->{vmid} == $vmid; # already reserved
> +
> + if (($pciid->{timestamp} + $graceperiod > $ctime) ||
> + PVE::QemuServer::Helpers::vm_running_locally($vmid))
> + {
style nit², we (nowadays) normally place the if's closing ) also on the new
line:
if (($pciid->{timestamp} + $graceperiod > $ctime) ||
PVE::QemuServer::Helpers::vm_running_locally($vmid)
) {
....
}
honestly I'd like it 1000% more the rust way, but well..
next prev parent reply other threads:[~2021-10-05 14:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-05 13:11 [pve-devel] [PATCH qemu-server 0/3] fix #3258: check for in-use pci devices on vm start Dominik Csapak
2021-10-05 13:11 ` [pve-devel] [PATCH qemu-server 1/3] pci: to not capture first group in PCIRE Dominik Csapak
2021-10-05 14:13 ` [pve-devel] applied: " Thomas Lamprecht
2021-10-05 13:11 ` [pve-devel] [PATCH qemu-server 2/3] pci: add helpers to (un)reserve pciids for a vm Dominik Csapak
2021-10-05 14:13 ` Thomas Lamprecht [this message]
2021-10-05 13:12 ` [pve-devel] [PATCH qemu-server 3/3] fix #3258: block vm start when pci device is already in use 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=90c1f81e-6cc0-36ce-9e84-d72ad7e7b578@proxmox.com \
--to=t.lamprecht@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.