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

[Fiona Ebner <f.ebner@proxmox.com>]

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.