From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <f.ebner@proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 293E49CB26 for <pve-devel@lists.proxmox.com>; Thu, 1 Jun 2023 10:34:42 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 09E7F1B896 for <pve-devel@lists.proxmox.com>; Thu, 1 Jun 2023 10:34:42 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for <pve-devel@lists.proxmox.com>; Thu, 1 Jun 2023 10:34:40 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 8D2CD480AA; Thu, 1 Jun 2023 10:34:40 +0200 (CEST) Message-ID: <edadfce9-d86f-4dad-e520-d1c65452dd4e@proxmox.com> Date: Thu, 1 Jun 2023 10:34:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 To: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>, "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>, "aderumier@odiso.com" <aderumier@odiso.com> References: <20230522102528.186955-1-aderumier@odiso.com> <ea2162bf-0fd7-77ee-fe04-1fa757c20a84@proxmox.com> <5ee559732b6d5d1d26462cc7d824cc159b13d3de.camel@groupe-cyllene.com> Content-Language: en-US From: Fiona Ebner <f.ebner@proxmox.com> In-Reply-To: <5ee559732b6d5d1d26462cc7d824cc159b13d3de.camel@groupe-cyllene.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 NICE_REPLY_A -0.091 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [PATCH-SERIES v3 qemu-server/manager/common] add and set x86-64-v2 as default model for new vms and detect best cpumodel X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Thu, 01 Jun 2023 08:34:42 -0000 Am 31.05.23 um 16:34 schrieb DERUMIER, Alexandre: > Le mercredi 31 mai 2023 à 13:36 +0200, Fiona Ebner a écrit : >> Am 22.05.23 um 12:25 schrieb Alexandre Derumier: >>> In addition to theses model, I have enabled aes too. >>> I think it's really important, because a lot of users use default >>> values and have >>> bad performance with ssl and other crypto stuffs. >>> >> >> So there is the answer to my aes question :) But shouldn't we rather >> set >> it via the UI as a default than change the CPU definition itself? >> That >> feels cleaner as we'd not diverge from how they defined the ABI. > > I don't have looked pve-manager code yet, but do you think it's easy > to auto enable/disable the aes flag in the grid when we choose theses > models ? I also haven't looked at the code, but yeah, it is an issue that it's in the advanced part and we shouldn't hide it from the user that it's on. > Maybe could it be better to have 2 differents models, with/without aes > (like some qemu models versions like -IBRS, > here we could have > > x86-64-v2 > x86-64-v2-aes (default) > x86-64-v3 > x86-64-v3-aes That might work, but if we do that, please only in the UI. Also not ideal, because how would interaction with the flag in the grid work? E.g. don't show it, force it on if an -aes model is selected? Maybe the easiest would be to extract the aes flag out of the grid into the non-advanced part?