From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 00C391FF133 for ; Mon, 11 May 2026 16:08:40 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 9482E1BF0B; Mon, 11 May 2026 16:08:38 +0200 (CEST) Message-ID: <7c07d82a-d646-4f9e-bad6-ffdde7fe95f7@proxmox.com> Date: Mon, 11 May 2026 16:08:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH docs/manager/qemu-server v4 00/17] Add API and UI for custom CPU models To: Arthur Bied-Charreton , pve-devel@lists.proxmox.com References: <20260430160109.565536-1-a.bied-charreton@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: <20260430160109.565536-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: 1778508401009 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.141 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment POISEN_SPAM_PILL 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes 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: 3Z2ZX2NDQDFF4WUM7BHFIUULHFZTTHN3 X-Message-ID-Hash: 3Z2ZX2NDQDFF4WUM7BHFIUULHFZTTHN3 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 30.04.26 um 5:59 PM schrieb Arthur Bied-Charreton: > This picks up and extends an old series [0] by Stefan Reiter. > > This series adds a full CRUD API and a UI editor for custom CPU models > which allows users to manage them in the Datacenter interface rather > than editing /etc/pve/virtual-guest/cpu-models.conf manually. > > It also improves on the existing VM CPU flags selector by providing a > list of nodes supporting each flag to help gauge cluster compatibility. > > qemu-server gets a new CPUFlags module grouping cpu-flags-related > helpers. A new helper (query_available_cpu_flags) is introduced, which > derives the set of flags accepted by QEMU as -cpu arguments and > annotates each with the cluster nodes that report supporting it. The > existing node-level endpoint is extended with an accel parameter to > filter flags by acceleration type. Its default behavior is preserved > modulo the added 'supported-on' field per flag in the return value. > > pve-manager gets two new cluster-level endpoints: > > 1. /cluster/qemu/cpu-flags queries flags available across the cluster > and reports which node supports each of them. It differs from the > node-level endpoint in qemu-server in that it returns *all* flags, > as opposed to the VM-specific ones. > > 2. /cluster/qemu/custom-cpu-models provides full CRUD for custom CPU > model definitions. > > The UI gets a "Custom CPU models" view in the Datacenter panel (at the > bottom under "Guest Resources/Hardware") with an editor for model > properties. The flags can now be filtered by acceleration type when > creating a new VM or custom CPU model, and it is pre-selected based on > the VM's KVM config key when editing a pre-existing VM's CPU. The CPU > flags selector is also improved with the option to filter out flags > that are not supported anywhere in the cluster. Very good work! I know I made a lot of comments and suggestions, but there are relatively few that I would consider blockers. The feature is shaping up nicely and most changes should be rather straight-forward. Except maybe the 'kvm' qm.conf checkbox might be a bit more work. If it's too much, we can also consider doing that later on. > Dependencies: > pve-manager requires bumped pve-docs Just for completeness/as a reminder: it build-depends on pve-doc-generator and depends on pve-docs. > pve-manager requires bumped qemu-server build+normal depends here.