From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 347861FF0ED for ; Fri, 31 Jul 2026 11:12:20 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 72CF721353; Fri, 31 Jul 2026 11:12:19 +0200 (CEST) Message-ID: Date: Fri, 31 Jul 2026 11:12:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC qemu/qemu-server 0/2] qemu: dump and ship CPU model expansions To: Arthur Bied-Charreton References: <20260730141522.203966-1-f.ebner@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1785489125726 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.158 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_LOW -0.7 Sender listed at https://www.dnswl.org/, low trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: QRTEEMTITMTCXFOWNMVIB63CIFCDG3J2 X-Message-ID-Hash: QRTEEMTITMTCXFOWNMVIB63CIFCDG3J2 X-MailFrom: f.ebner@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 CC: pve-devel@lists.proxmox.com, Erik Fastermann X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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.