From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id F2D67BA594 for ; Thu, 14 Dec 2023 10:47:17 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id CE10C14EAA for ; Thu, 14 Dec 2023 10:46:47 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Thu, 14 Dec 2023 10:46:47 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id DFA0047543 for ; Thu, 14 Dec 2023 10:46:46 +0100 (CET) Message-ID: Date: Thu, 14 Dec 2023 10:46:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Proxmox VE development discussion , Filip Schauer References: <20231213165848.107768-1-f.schauer@proxmox.com> From: Fiona Ebner In-Reply-To: <20231213165848.107768-1-f.schauer@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.077 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 SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [PATCH v5 qemu-server] Prevent starting a 32-bit VM using a 64-bit OVMF BIOS 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: , X-List-Received-Date: Thu, 14 Dec 2023 09:47:18 -0000 Am 13.12.23 um 17:58 schrieb Filip Schauer: > @@ -719,6 +731,26 @@ sub get_cpu_from_running_vm { > return $1; > } > > +sub get_cpu_bitness { Learned a new word today :) > + my ($conf, $arch) = @_; Please pass either the CPU property string or the CPU type directly instead of the whole config. Makes it more re-usable and modular. > + > + return if !$conf or !$arch; There always is an arch and a CPU type, so IMHO, we should make the caller responsible for passing in something valid. I.e. I'd rather die than "hide" the issue by returning undef. For the CPU type, we could also fall back to the default if nothing got passed in (we got access to $cpu_fmt in the module). > + > + if ($arch eq 'x86_64') { > + if (my $cpu_prop_str = $conf->{cpu}) { > + my $cpu = PVE::JSONSchema::parse_property_string('pve-vm-cpu-conf', $cpu_prop_str) > + or die "Cannot parse cpu description: $cpu_prop_str\n"; > + > + my $cputype = $cpu->{cputype}; > + return 32 if $cputypes_32bit->{$cputype}; > + } > + > + return 64; > + } > + > + return 64 if $arch eq 'aarch64'; > +} I'd rather die then return undef if it's an unknown arch. Then it will be more obvious if we forget to extend the helper. Because Perl itself will not complain if we forget.