From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 840141FF14C for ; Fri, 15 May 2026 11:29:29 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id DB086143DD; Fri, 15 May 2026 11:28:51 +0200 (CEST) From: Arthur Bied-Charreton To: pve-devel@lists.proxmox.com Subject: [PATCH qemu-server v5 06/21] cpu flags: add helper querying CPU flags with nodes supporting them Date: Fri, 15 May 2026 11:28:23 +0200 Message-ID: <20260515092839.238064-7-a.bied-charreton@proxmox.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260515092839.238064-1-a.bied-charreton@proxmox.com> References: <20260515092839.238064-1-a.bied-charreton@proxmox.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.134 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 KAM_LAZY_DOMAIN_SECURITY 1 Sending domain does not have any anti-forgery methods RDNS_NONE 0.793 Delivered to internal network by a host with no rDNS SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_NONE 0.001 SPF: sender does not publish an SPF Record Message-ID-Hash: OOU7GOTTS2UEN34RTDMBSF4PQNPJOGJ3 X-Message-ID-Hash: OOU7GOTTS2UEN34RTDMBSF4PQNPJOGJ3 X-MailFrom: abied-charreton@jett.proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: The get_supported_cpu_flags helper returns a hardcoded list of VM-specific flags, without any information on which nodes actually support them. Add query_available_cpu_flags, which annotates the flags QEMU recognizes as `-cpu` arguments with the nodes that actually support them to give an accurate picture of which flags will be accepted when starting a VM. Flags can be filtered by scope (vm-specific or all) and queried for the specific acceleration type (kvm/tcg), which determines which nodes report supporting which flag. This currently returns early when $arch is set to `aarch64`. This is intended for vm-specific flags, since there are none that are currently meant to be settable for VMs. For the general flags list, this is a limitation due to the fact that it is a lot harder to get a list of understood flags at QEMU build time for `aarch64`, as opposed to `x86_64`, where `-cpu help` will just list all of them. It is left for a future TODO. Signed-off-by: Arthur Bied-Charreton --- src/PVE/QemuServer/CPUFlags.pm | 132 +++++++++++++++++++++++++++++++++ 1 file changed, 132 insertions(+) diff --git a/src/PVE/QemuServer/CPUFlags.pm b/src/PVE/QemuServer/CPUFlags.pm index e17ed00c..709828d7 100644 --- a/src/PVE/QemuServer/CPUFlags.pm +++ b/src/PVE/QemuServer/CPUFlags.pm @@ -15,6 +15,7 @@ our @EXPORT_OK = qw( get_supported_cpu_flags query_understood_cpu_flags normalize_cpu_flag + query_available_cpu_flags ); my $supported_vm_specific_cpu_flags_by_arch = { @@ -154,6 +155,11 @@ sub supported_cpu_flags_names() { return @supported_cpu_flags_name_sorted; } +sub supported_cpu_flags_names_by_arch($arch) { + my @res = sort map { $_->{name} } $supported_vm_specific_cpu_flags_by_arch->{$arch}->@*; + return @res; +} + sub cpu_flag_supported_re() { return qr/([+-])(@{[join('|', supported_cpu_flags_names())]})/; } @@ -187,4 +193,130 @@ sub query_understood_cpu_flags($arch) { return \@flags; } +=head3 flag_is_vm_specific($flag) + +Return true if `$flag` may be set for a VM's CPU flags configuration. + +=cut + +sub flag_is_vm_specific($flag) { + return defined($all_supported_vm_specific_cpu_flags->{$flag}); +} + +sub flag_descriptions($arch) { + return { map { $_->{name} => $_->{description} } + $supported_vm_specific_cpu_flags_by_arch->{$arch}->@* }; +} + +=head3 query_available_cpu_flags($accel, $vm_specific, $arch) + +Retrieve a list of available flags, i.e., flags that will be accepted by PVE in a +processor config when attempting to spawn a VM. Each flag is returned along with a list +of nodes that support it. Flags that are not supported on any node are also returned; +filtering them out is up to the consumer of this API. + +B + +=over + +=item C<$accel> (C | C) + +Selects which acceleration type flag/node compatibility should be evaluated for. + +=item C<$vm_specific> (boolean) + +When set to 1, return only VM-specific flags, otherwise return all flags. + +=item C<$arch> (C | C) + +Specifies which architecture to query flags for. Note that in both scopes (VM-specific +and all), C returns empty lists: this is intended for VM-specific flags, as no +C flags are currently settable for a specific VM, however it is a known +limitation for the "all" scope. PVE does not currently ship a list of understood flags +for C, as it is not as trivial to obtain as for C, whose flags are easy +to parse from QEMU's C<-cpu help> output. + +=back + +In order to get an accurate picture of which flags can actually be used, two sources are +combined (see C for details): + +=over + +=item 1. + +The B CPU flags, i.e., all flags QEMU accepts as C<-cpu> arguments in +principle, regardless of whether the host CPU actually supports them. + +=item 2. + +The B CPU flags: the flags the host CPU actually supports, cached in the node +KV store by C. This is node-specific. + +=back + +Each flag from (1) is annotated with the subset of nodes from (2) that report supporting +it. + +=cut + +sub query_available_cpu_flags($accel, $vm_specific, $arch) { + # TODO: a way to get supported flags for aarch64. This is not done because PVE + # does not currently ship a list of understood flags for aarch64, as it's more difficult + # to obtain during QEMU build - for x86_64, qemu -cpu help will just list the flags. + return [] if $arch eq 'aarch64'; + + my $descriptions = flag_descriptions($arch); + my $base = + !$vm_specific + ? query_understood_cpu_flags($arch) + : [supported_cpu_flags_names_by_arch($arch)]; + my $available_flags = { + map { + $_ => { name => $_, 'supported-on' => {}, description => $descriptions->{$_} } + } @$base + }; + + my $kv_store = "cpuflags-$accel"; + my $flags = PVE::Cluster::get_node_kv($kv_store); + + $available_flags->{'nested-virt'} = { + name => 'nested-virt', + 'supported-on' => {}, + description => $descriptions->{'nested-virt'}, + }; + + my $add_flag = sub($node, $name) { + return if !defined($available_flags->{$name}); + $available_flags->{$name}->{'supported-on'}->{$node} = 1; + }; + + for my $node (keys %$flags) { + # This depends on `pvestatd` storing the flags in space-separated format, which + # is the case at the time of this commit. + for (split(' ', $flags->{$node})) { + my $pve_alias = undef; + $pve_alias = 'nested-virt' if $_ eq 'svm' || $_ eq 'vmx'; + next if $vm_specific && !flag_is_vm_specific($_) && !$pve_alias; + $add_flag->($node, $_) if !($vm_specific && $pve_alias); + $add_flag->($node, $pve_alias) if $pve_alias; + } + } + + for my $flag (values %$available_flags) { + $flag->{'supported-on'} = [sort keys $flag->{'supported-on'}->%*]; + } + + # Make sure 'nested-virt' is always shown first. + my $nested_virt = delete $available_flags->{'nested-virt'}; + + # Order flags that are not supported anywhere in the cluster to the end. + my @sorted = sort { + (scalar($a->{'supported-on'}->@*) == 0) <=> (scalar($b->{'supported-on'}->@*) == 0) + || $a->{name} cmp $b->{name} + } values %$available_flags; + + return [defined($nested_virt) ? ($nested_virt, @sorted) : @sorted]; +} + 1; -- 2.47.3