From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 1AA429CBB9 for ; Thu, 1 Jun 2023 11:17:57 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E734E1C113 for ; Thu, 1 Jun 2023 11:17:26 +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 ; Thu, 1 Jun 2023 11:17:26 +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 EBDFB480E3; Thu, 1 Jun 2023 11:17:25 +0200 (CEST) Message-ID: Date: Thu, 1 Jun 2023 11:17:25 +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: "DERUMIER, Alexandre" , "pve-devel@lists.proxmox.com" , "aderumier@odiso.com" References: <20230522102528.186955-1-aderumier@odiso.com> <20230522102528.186955-2-aderumier@odiso.com> From: Fiona Ebner In-Reply-To: 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 v3 qemu-server 1/7] cpuconfig: add new x86-64-vX models X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2023 09:17:57 -0000 Am 31.05.23 um 17:08 schrieb DERUMIER, Alexandre: >>>   >>> +my $builtin_models = { >>> +    'x86-64-v1' => { >>> +       'reported-model' => 'Opteron_G1', >> >> It's unfortunate that we'll report this model and hence also AMD as >> vendor even on Intel hosts and vice versa for the other models. We >> could >> set the vendor to the host's vendor (in get_cpu_options() handle >> getting >> the vendor for the built-in models differently),  > I think it'll break if you migrate between intel/amd host anyway ? That's true :) >> but that's also >> strange, because then it would be Opteron_G1 with vendor GenuineIntel >> :/ >> So maybe better to just leave it? > Well, kvm64 guest have vendor Authentic amd (even on intel host;), with > modelname "common kvm processor") > cat /proc/cpuinfo > vendor_id : AuthenticAmd > model name : "Common KVM processor" Are you sure? Or was this a migrated machine? We have this comment > # generic types, use vendor from host node > host => 'default', > kvm32 => 'default', > kvm64 => 'default', and for a colleague, it is GenuineIntel with kvm64 on an Intel host. > If we don't want to expose the original modelname from where we > derivate, afaik, the only way is to patch qemu directly (like in my > v1). We can actually just use the model-id option for -cpu and I think we should for these built-in models. I.e. set the vendor to the one from the host and the model-id to something generic too. Maybe "Common x86_64-abi1-compatible processor", but that feels involved, or maybe just "Common KVM processor" again? >> >>> +       flags => "-vme;-svm;-vmx", >> >> Why remove the svm and vmx flags? They are not exposed by us, so a >> user >> cannot even enable them back if needed, but needs to switch to a >> different CPU type. > yes, that's was the idea to forbid user to enable them, as it's > breaking livemigration, so it don't make any sense to use this model > instead host model. > > But I can remove them, no problem. Oh, I missed the following in the referenced mail: > None of the CPU models declare any VMX/SVM capability features. > IOW, even if a "vmx"/"svm" flag is added, it will still be unsafe > to attempt to live migrate the L1 guest if there are any L2 > guests running with hardware virtualization. Please keep them off then. >>> @@ -96,6 +115,9 @@ my $cpu_vendor_list = { >>>      kvm64 => 'default', >>>      qemu32 => 'default', >>>      qemu64 => 'default', >>> +    'x86-64-v1' => 'default', >>> +    'x86-64-v2' => 'default', >>> +    'x86-64-v3' => 'default', >> >> >> Currently all of the others are actual models we can pass directly to >> QEMU/KVM. I'd rather not add these custom built-in ones here. You'll >> need to adapt validate_vm_cpu_conf() of course, to also accept the >> built-in ones. >> >> Because of adding them here, I can also set them as the 'reported- >> model' >> for a custom CPU in /etc/pve/virtual-guest/cpu-models.conf and >> parsing >> the file will work, but then starting a VM with that custom CPU will >> fail with kvm: unable to find CPU model 'x86-64-v1'. >> >> If we'd like to enable using the built-in ones as base for custom CPU >> models, we'll need to handle them differently, but I'm not sure we >> should until there is enough user demand. >> > Maybe it could be simplier to really add true build-model in qemu ? > (The qemu patch is pretty small, and shouldn't be difficult to > maintain) > > I'm not sure, but maybe user will think that it's strange than x86-64- > v2 will display nahelem in guest && in qemu command line ? > Yes, for this it would be easier, but I also don't think we need to allow these as a base for custom models (at least not until there is enough user demand). And we can still switch later to make them true QEMU models if we really need to.