From: Arthur Bied-Charreton <a.bied-charreton@proxmox.com>
To: Fiona Ebner <f.ebner@proxmox.com>
Cc: pve-devel@lists.proxmox.com
Subject: Re: [RFC qemu/qemu-server 0/2] qemu: dump and ship CPU model expansions
Date: Fri, 31 Jul 2026 10:09:46 +0200 [thread overview]
Message-ID: <xukxplzpzhym2zxkawmtrkrcibljvn4e6oorq6lwjkmadatbob@o5ii5mz4zzys> (raw)
In-Reply-To: <20260730141522.203966-1-f.ebner@proxmox.com>
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
>
>
>
>
next prev parent reply other threads:[~2026-07-31 8:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-30 14:15 [RFC qemu/qemu-server 0/2] qemu: dump and ship CPU model expansions Fiona Ebner
2026-07-30 14:15 ` [PATCH qemu-server 2/2] cpu flags: introduce get_cpu_model_expansions() helper Fiona Ebner
2026-07-31 8:09 ` Arthur Bied-Charreton [this message]
2026-07-31 9:12 ` [RFC qemu/qemu-server 0/2] qemu: dump and ship CPU model expansions Fiona Ebner
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=xukxplzpzhym2zxkawmtrkrcibljvn4e6oorq6lwjkmadatbob@o5ii5mz4zzys \
--to=a.bied-charreton@proxmox.com \
--cc=f.ebner@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.