Re: [pve-devel] [PATCH v5 qemu-server] Prevent starting a 32-bit VM using a 64-bit OVMF BIOS

[Filip Schauer <f.schauer@proxmox.com>]

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.