From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 51F9D1FF0AE for ; Tue, 13 Oct 2026 11:19:20 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 7F00220BEE; Tue, 13 Oct 2026 11:19:16 +0200 (CEST) Message-ID: <3cde24de-d79f-424c-b779-c0e22140faec@proxmox.com> Date: Tue, 13 Oct 2026 11:19:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH pve-qemu] parse-cpu-flags: stop filtering out 'pmu' To: Arthur Bied-Charreton , pve-devel@lists.proxmox.com References: <20261013083151.262823-1-a.bied-charreton@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: <20261013083151.262823-1-a.bied-charreton@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1791883151378 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.434 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_MED -2.3 Sender listed at https://www.dnswl.org/, medium 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: MVX6ISKZEJFYDQQKKHJKV7UXIMSOL4E5 X-Message-ID-Hash: MVX6ISKZEJFYDQQKKHJKV7UXIMSOL4E5 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 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 13.10.26 um 10:32 AM schrieb Arthur Bied-Charreton: > 'pmu' was excluded from the list of flags in the custom CPU flag dialog > because it is not a CPUID flag (not part of '-cpu help' output). > However, it is a plain boolean property so it fits the [+-] syntax > from the custom CPU config, and QEMU accepts it when set manually via > '+pmu'. What I wanted to write: if it's not a CPUID flag, wouldn't it be better to expose it as a separate property? I.e. add to the $cpu_fmt schema and have a separate checkbox in the UI? But then I looked into the implementation and the 'pmu' property is very closely related to the CPUID_EXT_PDCM flag, so it makes a lot of sense if it goes through the same "on which nodes is it supported" checks and if we treat it as a flag. Could you adapt the commit message to reflect this? IMHO the argument with QEMU accepting the same syntax is rather weak. There has to be conceptual similarity too, which there is :) > > Windows guests using VBS need a virtual PMU, which is not enabled by > default on many models (EPYC-Turin, EPYC-Genoa, SapphireRapids, and > presumably others I have not tested). This currently requires users to > edit the config by hand since the flag cannot be selected in the UI. > > Remove 'pmu' from the blacklist so it shows up in the generated flag > list. > > Reported-by: David Riley > Signed-off-by: Arthur Bied-Charreton > --- > debian/parse-cpu-flags.pl | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/debian/parse-cpu-flags.pl b/debian/parse-cpu-flags.pl > index e680f99..e1af0e8 100755 > --- a/debian/parse-cpu-flags.pl > +++ b/debian/parse-cpu-flags.pl > @@ -66,7 +66,6 @@ my $filtered_props = { > 'legacy-multi-node' => 1, > lmce => 1, > migratable => 1, > - pmu => 1, > realized => 1, > 'start-powered-off' => 1, > 'tcg-cpuid' => 1, Note: you also need to add it to debian/recognized-CPUID-flags-x86_64