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 CA1B19C284 for <pve-devel@lists.proxmox.com>; Wed, 31 May 2023 13:36:43 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id AB0DE8E55 for <pve-devel@lists.proxmox.com>; Wed, 31 May 2023 13:36:43 +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)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for <pve-devel@lists.proxmox.com>; Wed, 31 May 2023 13:36:43 +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 B6BB347EBF; Wed, 31 May 2023 13:36:42 +0200 (CEST) Message-ID: <ea2162bf-0fd7-77ee-fe04-1fa757c20a84@proxmox.com> Date: Wed, 31 May 2023 13:36:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>, Alexandre Derumier <aderumier@odiso.com> References: <20230522102528.186955-1-aderumier@odiso.com> From: Fiona Ebner <f.ebner@proxmox.com> In-Reply-To: <20230522102528.186955-1-aderumier@odiso.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.004 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.09 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: Wed, 31 May 2023 11:36:43 -0000 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. > > This was discussed on the qemu mailing > > " > Crypto accelerator caveats > ========================== > > Similarly I'm not a huge fan of leaving out the "aes" > instruction for accelerated crypto, as missing "aes" is > also one of the key factors in making qemu64 a bad choice. > > If we include 'aes' in x86-64-v2, then we loose support > for Nehalem hosts. > > If we include 'aes' in x86-64-v3 then we further loose > support for Dhyana hosts (an EPYC derived CPU). > " > > Nahelemn is a 2008 cpu, so I think it's ok, we are in 2013 ;) > (and user can disable aes flag in gui too) > > That mean than the minimum compatible cpu for v2 is Intel Westmere (2010) > and Amd Bulldozer (2011). > Additionnaly, it could be great to use a real cpu model when we don't have > mixed intel/amd cluster, to have spectre/meltdown/.... mitigations enabled. > > I have added initial code for best model detection based on host cpuflags > vs qemu models flags. > > Not yet plugged, I'm not sure what is the best way, only at vm create, > or at vm start to auto upgrade vm cpu to last version ? > I'm not sure with cluster, if user add a new older node. > (vmware have a feature called EVC, compute the best model when node join/leave) > If we do this, then only at VM create. Changing the CPU at VM start is just too much magic and can break things, because we don't know what the guest is fine with. Much of the problem would already be solved by having something like https://bugzilla.proxmox.com/show_bug.cgi?id=3500 where the admin can select a sane default for their cluster and we can help them choose a default with some guidance in the documentation. A way to calculate the best model in the cluster can be fine, but seems to be quite an effort. If we deem it worth it, we can still have a separate "calculate best model" tool/command. Changing such things automatically just leads to unexpected surprises.