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 53BD61FF140 for ; Fri, 27 Mar 2026 14:28:30 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 661A0B017; Fri, 27 Mar 2026 14:28:51 +0100 (CET) Message-ID: <21976f11-3da8-4e35-9586-a20bdcdf7a19@proxmox.com> Date: Fri, 27 Mar 2026 14:28:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH manager/qemu-server 0/8] Add API and UI for custom CPU models To: Arthur Bied-Charreton References: <20260312084021.124465-1-a.bied-charreton@proxmox.com> <6a0a3489-d0c5-4995-9ca8-caa19260d619@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: 1774618076914 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.003 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 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. 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: NJBTX46556SFWCWLNYZSEMATK36FRUVZ X-Message-ID-Hash: NJBTX46556SFWCWLNYZSEMATK36FRUVZ 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 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 27.03.26 um 2:06 PM schrieb Arthur Bied-Charreton: > On Thu, Mar 26, 2026 at 03:54:53PM +0100, Fiona Ebner wrote: >> Am 12.03.26 um 9:40 AM schrieb Arthur Bied-Charreton: >>> This is picked up from an old series [0] by Stefan Reiter. >>> >>> As of before this series, the only way to create custom CPU models is by >>> editing `/etc/pve/virtual-guest/cpu-models.conf` manually. >>> >>> This can be cumbersome for a few reasons, e.g., due to the fact that flags >>> misconfigurations are only caught when starting the VM. >>> >>> `cpu-flags` endpoint: >>> The `cpu-flags` endpoint previously returned a list of hardcoded flags, >>> which is both non-exhaustive (some flags I should be able to set are missing), >>> and partly incorrect (some flags my host(s) do not support set are returned). >>> This is limiting and can lead to misconfigurations. The updated endpoint >>> intersects all flags QEMU accepts as `-cpu` arguments with all flags the host >>> hardware/emulation actually supports. This way, if I am able to set a flag in >>> the UI, I can be confident that the VM will actually be able to start. >>> >>> Custom CPU model CRUD functionality: >>> Expose CRUD endpoints and UI flow to interact with `cpu-models.conf`. For each >>> flag, show a list of the cluster nodes supporting it, and only expose flags that >>> at least one node supports to avoid misconfigurations. Filter flags by >>> acceleration type (KVM/TCG). >>> >>> [0] https://lore.proxmox.com/pve-devel/20211028114150.3245864-1-s.reiter@proxmox.com/ >> >> With a pre-existing, manually added model: >> >> [I] root@pve9a1 ~# cat /etc/pve/virtual-guest/cpu-models.conf >> cpu-model: nested-for-wsl >> flags +svm >> hidden 1 >> hv-vendor-id AuthenticAMD >> reported-model EPYC >> >> When opening it up in the UI, the editor seems to immediately detect a >> change, i.e. the OK button is clickable and when I click it, I get the >> following error: >> >> Parameter verification failed. (400) >> flags: value does not match the regex pattern >> > Thanks a lot for catching that! > >> It seems to be because of the 'svm' flag not being in the flags grid. > Yes, just confirmed that. >> Since users might've already added such models manually, it would be >> nice if it would work. Maybe list the unknown flags in the grid without >> description? > Yes, I will display unknown flags in the grid with empty supported-on > fields. > > On this topic: I currently manually filter out occurrences of svm/vmx to > replace them with nested-virt. Would it make sense to still display them > in the flags selector, even if they overlap with our abstraction? I think we can still show them and don't need to filter them out. In particular, not having the 'supported-on' for those flags can also lead to confusion, as can (artificially) hiding them from users. I don't see why we should force people to use the abstract 'nested-virt'. It can be convenient for mixed-CPU-vendor clusters, and having the flag be part of the VM-specific ones was the main motivation to add it.