[RFC qemu/qemu-server 0/2] qemu: dump and ship CPU model expansions

[RFC qemu/qemu-server 0/2] qemu: dump and ship CPU model expansions

[Fiona Ebner]

Sending this, so Arthur and Erik can look into it for issue #7841.

Having the CPU model expansions readily available makes it possible to
be precise when checking for the presence of certain CPU flags or
properties. For example, the pdpe1gb flag is relevant since OVMF will
limit the phys-bits to 40 without that. Starting a QEMU process to
query this via QMP is too costly in many cases, so qemu-server is
currently limited to use heuristics.

Having the flags can also be useful for the custom CPU model editor to
show what the default value for a given flag and model actually is.

The one for x86_64 is rather large with 1.65 MiB, but it can be loaded
on first use and then cached by the CPUConfig.pm module.

It's important to be aware that some features/flags are gated behind
others, most prominently, the nested virtualization ones.

pve-qemu:

Fiona Ebner (1):
  d/rules: dump and ship CPU model expansions

 debian/cpu-model-expansions-aarch64.json |   220 +
 debian/cpu-model-expansions-x86_64.json  | 51268 +++++++++++++++++++++
 debian/dump-cpu-model-expansions.pl      |    66 +
 debian/rules                             |    10 +
 4 files changed, 51564 insertions(+)
 create mode 100644 debian/cpu-model-expansions-aarch64.json
 create mode 100644 debian/cpu-model-expansions-x86_64.json
 create mode 100755 debian/dump-cpu-model-expansions.pl


qemu-server:

Fiona Ebner (1):
  cpu flags: introduce get_cpu_model_expansions() helper

 src/PVE/QemuServer/CPUFlags.pm | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)


Summary over all repositories:
  5 files changed, 51591 insertions(+), 0 deletions(-)

-- 
Generated by git-murpp 0.5.0

[PATCH qemu-server 2/2] cpu flags: introduce get_cpu_model_expansions() helper

[Fiona Ebner]

Make the static list of CPU model expansions, which is newly shipped
by pve-qemu-kvm, accessible in qemu-server.

Note that some CPU flags in the expansions are gated behind others and
thus cannot be queried via the static expansions. Most prominently,
this is the case for the flags for nested virtualization. For example,
'Skylake-Server' will not support any vmx-* flags, but
'Skylake-Server,+vmx' would.

Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
---
 src/PVE/QemuServer/CPUFlags.pm | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/src/PVE/QemuServer/CPUFlags.pm b/src/PVE/QemuServer/CPUFlags.pm
index 0d3206b2..60683486 100644
--- a/src/PVE/QemuServer/CPUFlags.pm
+++ b/src/PVE/QemuServer/CPUFlags.pm
@@ -3,6 +3,7 @@ package PVE::QemuServer::CPUFlags;
 use v5.36;
 
 use Exporter qw(import);
+use JSON qw();
 
 use PVE::Cluster;
 use PVE::File;
@@ -129,6 +130,32 @@ my $qemu_cpu_flag_alias_map = {
     lbr_fmt => 'lbr-fmt',
 };
 
+my $cpu_model_expansions;
+
+=head3 get_cpu_model_expansions($arch)
+
+Get the CPU model expansions for the given architecture C<$arch>. Will return C<undef> for QEMU
+package versions that don't yet ship the static model expansions. Note that some CPU flags in the
+expansions are gated behind others and thus cannot be queried via the static expansions. Most
+prominently, this is the case for the flags for nested virtualization. For example,
+C<Skylake-Server> will not support any C<vmx-*> flags, but C<Skylake-Server,+vmx> would. The latter
+cannot be queried here.
+
+=cut
+
+my sub get_cpu_model_expansions($arch) {
+    if (!defined($cpu_model_expansions->{$arch})) {
+        my $cpu_models_file = "/usr/share/kvm/cpu-model-expansions-${arch}.json";
+        return if !PVE::File::file_exists($cpu_models_file);
+
+        my $data = PVE::File::file_get_contents($cpu_models_file, 10 * 1024 * 1024);
+
+        $cpu_model_expansions->{$arch} = JSON::decode_json($data);
+    }
+
+    return $cpu_model_expansions->{$arch};
+}
+
 =head3 normalize_cpu_flag($flag)
 
 Normalize a CPU flag to its QEMU form.
-- 
2.47.3

Re: [RFC qemu/qemu-server 0/2] qemu: dump and ship CPU model expansions

[Arthur Bied-Charreton]

On Thu, Jul 30, 2026 at 04:15:08PM +0200, Fiona Ebner wrote:
> Sending this, so Arthur and Erik can look into it for issue #7841.
> 
> Having the CPU model expansions readily available makes it possible to
> be precise when checking for the presence of certain CPU flags or
> properties. For example, the pdpe1gb flag is relevant since OVMF will
> limit the phys-bits to 40 without that. Starting a QEMU process to
> query this via QMP is too costly in many cases, so qemu-server is
> currently limited to use heuristics.
> 
> Having the flags can also be useful for the custom CPU model editor to
> show what the default value for a given flag and model actually is.
> 
> The one for x86_64 is rather large with 1.65 MiB, but it can be loaded
> on first use and then cached by the CPUConfig.pm module.
> 
> It's important to be aware that some features/flags are gated behind
> others, most prominently, the nested virtualization ones.
> 
Thanks for sending this! Wouldn't it make more sense to build this
directly in such a way that we can query model expansions dynamically
though? As far as I can tell, gated flags mean that, as soon as a CPU 
config has one flag set/unset (which I think is a pretty common case),
we cannot rely on the static file anymore. There might be a way to find
out which features gate others, but this seems like a workaround that 
could be avoided entirely with dynamic queriability.

What do you think?
> pve-qemu:
> 
> Fiona Ebner (1):
>   d/rules: dump and ship CPU model expansions
> 
>  debian/cpu-model-expansions-aarch64.json |   220 +
>  debian/cpu-model-expansions-x86_64.json  | 51268 +++++++++++++++++++++
>  debian/dump-cpu-model-expansions.pl      |    66 +
>  debian/rules                             |    10 +
>  4 files changed, 51564 insertions(+)
>  create mode 100644 debian/cpu-model-expansions-aarch64.json
>  create mode 100644 debian/cpu-model-expansions-x86_64.json
>  create mode 100755 debian/dump-cpu-model-expansions.pl
> 
> 
> qemu-server:
> 
> Fiona Ebner (1):
>   cpu flags: introduce get_cpu_model_expansions() helper
> 
>  src/PVE/QemuServer/CPUFlags.pm | 27 +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
> 
> 
> Summary over all repositories:
>   5 files changed, 51591 insertions(+), 0 deletions(-)
> 
> -- 
> Generated by git-murpp 0.5.0
> 
> 
> 
> 

Re: [RFC qemu/qemu-server 0/2] qemu: dump and ship CPU model expansions

[Fiona Ebner]

Am 31.07.26 um 10:09 AM schrieb Arthur Bied-Charreton:
> On Thu, Jul 30, 2026 at 04:15:08PM +0200, Fiona Ebner wrote:
>> Sending this, so Arthur and Erik can look into it for issue #7841.
>>
>> Having the CPU model expansions readily available makes it possible to
>> be precise when checking for the presence of certain CPU flags or
>> properties. For example, the pdpe1gb flag is relevant since OVMF will
>> limit the phys-bits to 40 without that. Starting a QEMU process to
>> query this via QMP is too costly in many cases, so qemu-server is
>> currently limited to use heuristics.
>>
>> Having the flags can also be useful for the custom CPU model editor to
>> show what the default value for a given flag and model actually is.
>>
>> The one for x86_64 is rather large with 1.65 MiB, but it can be loaded
>> on first use and then cached by the CPUConfig.pm module.
>>
>> It's important to be aware that some features/flags are gated behind
>> others, most prominently, the nested virtualization ones.
>>
> Thanks for sending this! Wouldn't it make more sense to build this
> directly in such a way that we can query model expansions dynamically
> though? As far as I can tell, gated flags mean that, as soon as a CPU 
> config has one flag set/unset (which I think is a pretty common case),
> we cannot rely on the static file anymore. There might be a way to find
> out which features gate others, but this seems like a workaround that 
> could be avoided entirely with dynamic queriability.
> 
> What do you think?

We already discussed this off-list with the downsides:
1. spawning a new QEMU instance for each query is quite wasteful
2. having a daemon for querying introduces a single point of failure

And we need to query on every single flag change to get the full
picture. That is, except if we also track the feature gating flags.
There is a feature_dependencies[] definition in target/i386/cpu.c, so we
know what they are. Not sure if worth the additional complexity though.

Having static information is much cheaper and robust. But yes, it would
only be a heuristic once feature gating flags are set. We could improve
it by querying each model multiple times during dumping, with different
feature gating flags enabled and also recording that delta to the pure
model. Also not sure if it's worth the complexity. The advantage is that
the complexity is limited to the dumping. It would make the rest cheap.

I sent this so you can consider this approach too. It's not a NAK
towards the others.