public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Fiona Ebner <f.ebner@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
	Filip Schauer <f.schauer@proxmox.com>
Subject: Re: [pve-devel] [PATCH v5 qemu-server] Prevent starting a 32-bit VM using a 64-bit OVMF BIOS
Date: Thu, 14 Dec 2023 10:46:46 +0100	[thread overview]
Message-ID: <e840e47a-04ce-4f3e-8b04-2355edf8c395@proxmox.com> (raw)
In-Reply-To: <20231213165848.107768-1-f.schauer@proxmox.com>

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.




  reply	other threads:[~2023-12-14  9:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-13 16:58 Filip Schauer
2023-12-14  9:46 ` Fiona Ebner [this message]
2023-12-14 11:10   ` Filip Schauer

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=e840e47a-04ce-4f3e-8b04-2355edf8c395@proxmox.com \
    --to=f.ebner@proxmox.com \
    --cc=f.schauer@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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal