Patch v6 available:
https://lists.proxmox.com/pipermail/pve-devel/2023-December/061097.html
On 14/12/2023 10:46, Fiona Ebner wrote:
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.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
