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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox