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 C8FD81FF13F for ; Thu, 26 Mar 2026 16:10:19 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id CCB7C17ACC; Thu, 26 Mar 2026 16:10:39 +0100 (CET) Message-ID: Date: Thu, 26 Mar 2026 16:10:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH pve-manager 4/8] ui: Add basic custom CPU model editor To: Arthur Bied-Charreton , pve-devel@lists.proxmox.com References: <20260312084021.124465-1-a.bied-charreton@proxmox.com> <20260312084021.124465-5-a.bied-charreton@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: <20260312084021.124465-5-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: 1774537785762 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.005 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 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: YURB2VVVWC4KGBP5X4LVO6PPUE4QGYDF X-Message-ID-Hash: YURB2VVVWC4KGBP5X4LVO6PPUE4QGYDF 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 12.03.26 um 9:40 AM schrieb Arthur Bied-Charreton: > diff --git a/www/manager6/dc/CPUTypeEdit.js b/www/manager6/dc/CPUTypeEdit.js > new file mode 100644 > index 00000000..8cf508b4 > --- /dev/null > +++ b/www/manager6/dc/CPUTypeEdit.js Could also use an onlineHelp reference ---snip 8<--- > + { > + xtype: 'CPUModelSelector', > + fieldLabel: gettext('Reported Model'), What about 'Base Model' with a tooltip that it's reported to the guest (if that is even necessary)? I feel like 'Reported Model' doesn't make it clear that the rest of the configuration is applied based off that model. > + allowCustom: false, > + name: 'reported-model', > + }, ---snip 8<--- > diff --git a/www/manager6/dc/CPUTypeView.js b/www/manager6/dc/CPUTypeView.js > new file mode 100644 > index 00000000..c79ce690 > --- /dev/null > +++ b/www/manager6/dc/CPUTypeView.js > @@ -0,0 +1,139 @@ > +Ext.define('pve-custom-cpu-type', { > + extend: 'Ext.data.Model', > + fields: [ > + 'cputype', > + 'reported-model', > + 'hv-vendor-id', > + 'flags', > + 'phys-bits', > + { name: 'hidden', type: 'boolean' }, > + ], > +}); > + > +Ext.define('PVE.dc.CPUTypeView', { > + extend: 'Ext.grid.GridPanel', > + alias: ['widget.pveCPUTypeView'], > + > + onlineHelp: 'qm_cpu', Maybe link directly to the CPU type section? ---snip 8<--- > + columns: [ > + { > + header: gettext('Name'), > + flex: 1, > + dataIndex: 'cputype', > + renderer: (val) => val.replace(/^custom-/, ''), > + }, > + { > + header: gettext('Reported Model'), Same as above, I'd prefer "Base Model". > + flex: 1, > + dataIndex: 'reported-model', > + }, > + { > + header: gettext('Phys-Bits'), > + flex: 1, > + dataIndex: 'phys-bits', > + }, > + { > + header: gettext('Hidden'), > + flex: 1, > + dataIndex: 'hidden', > + }, > + { > + header: gettext('HyperV-Vendor'), > + flex: 1, > + dataIndex: 'hv-vendor-id', > + }, > + { > + header: gettext('Flags'), > + flex: 2, > + dataIndex: 'flags', > + }, > + ], > + > + tbar: [ > + { > + text: gettext('Add'), > + handler: 'onAdd', > + }, > + '-', > + { > + xtype: 'proxmoxStdRemoveButton', > + baseurl: '/api2/extjs/nodes/localhost/capabilities/qemu/cpu/model/', > + getRecordName: (rec) => rec.data.cputype, > + getUrl: function (rec) { > + let me = this; > + return me.baseurl + rec.data.cputype; > + }, > + callback: 'reload', Currently, the confirm dialog shows: "Are you sure you want to remove entry 'custom-nested-for-wsl'?" Would be nicer along the lines of "Are you sure you want to remove the custom CPU model 'nested-for-wsl'" if that can be done without much effort. Otherwise, not too important. > + }, > + { > + text: gettext('Edit'), > + handler: 'onEdit', > + }, > + ], > + > + selModel: { > + xtype: 'rowmodel', > + }, > + > + listeners: { > + itemdblclick: function (_, rec) { > + let me = this; > + me.getController().showEditor(rec.data.cputype); > + }, > + }, > + > + initComponent: function () { > + let me = this; > + me.callParent(); > + Proxmox.Utils.monStoreErrors(me, me.store); > + }, > +}); > diff --git a/www/manager6/dc/Config.js b/www/manager6/dc/Config.js > index b5e27a21..629e4fc8 100644 > --- a/www/manager6/dc/Config.js > +++ b/www/manager6/dc/Config.js > @@ -146,6 +146,12 @@ Ext.define('PVE.dc.Config', { > title: gettext('Replication'), > itemId: 'replication', > }, > + { > + xtype: 'pveCPUTypeView', > + iconCls: 'fa fa-microchip', > + title: gettext('Custom CPU models'), > + itemId: 'cputypes', > + }, I feel like this might better fit further below, after the directory and resource mappings items. I wonder if we should collect the two mappings and this in a common section, but I can't come up with a good name right now, something akin to "Guest Resources/Hardware"? But that is something to be further discussed so should be ordered at the end of the series or as a follow-up.