From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 65E111FF0AF for ; Thu, 24 Sep 2026 14:25:32 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id C69E22165B; Thu, 24 Sep 2026 14:25:29 +0200 (CEST) Message-ID: Date: Thu, 24 Sep 2026 14:25:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [RFC qemu-server v2 0/4] fix #7282: allow (NUMA aware) vCPU pinning To: Elias Huhsovitz , pve-devel@lists.proxmox.com References: <20260921095404.61552-1-e.huhsovitz@proxmox.com> Content-Language: en-US From: Dominik Csapak In-Reply-To: <20260921095404.61552-1-e.huhsovitz@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1790252726378 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.428 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust 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: C5JG25LIL6XILRKMBXNYAEX6FFERSFHJ X-Message-ID-Hash: C5JG25LIL6XILRKMBXNYAEX6FFERSFHJ X-MailFrom: d.csapak@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: I'm in the progress of looking through the code, but want to give some high level feedback 'early' I think the approach goes to far for what was intended: The pinning setting now also influences memory behavior but we already have the numaX options for that, the intention was that this is just related to the virtual cores. I'd prefer for it to stay that way. If we want to modify the memory handling, we'll have to do that in the memory/numa/etc. options (or a new separate one) but don't conflate it with the CPU pinning. Also, AFAIU this can also change the guest hardware depending on the host topology no? If yes, this is a no-go since this breaks live migration, potentially suspend/resume and backup/restore. It also can mess up the guest licensing when this is fixed for some sockets for example. In general such an options should never overwrite the explicit values in the config. Iff we want such a thing, this must be reflected in the sockets/cores/etc config (e.g. by setting 'auto' or some thing) and must be live migration blocker. In a first applied version I'd really like for it to focus on pinning vcpus on specific cores (or sets of cores). This should be opt-in and align with already existing options (such as numa/memory/sockets/etc) and not break live migration (e.g. it is ok to pin to different cpus/hostnodes on another node, but the hardware must stay the same) Making memory hostnode selection automatic and inferring guest topology can also make sense, but should be a separate patch/series and isn't really what the bug was about. Let's keep the focus narrow, this also will make the patches smaller and more easily digestible ;) I'll answer on the individual patches for style/code things too