[pve-devel] [PATCH v5 qemu-server] Prevent starting a 32-bit VM using a 64-bit OVMF BIOS
Filip Schauer
f.schauer at proxmox.com
Thu Dec 14 12:10:50 CET 2023
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.
More information about the pve-devel
mailing list