From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 304161FF16B for ; Fri, 7 Nov 2025 12:33:05 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id DD789EF84; Fri, 7 Nov 2025 12:33:45 +0100 (CET) Message-ID: Date: Fri, 7 Nov 2025 12:33:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Proxmox VE development discussion , Daniel Kral References: <20251031122834.62482-1-f.ebner@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1762515172377 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.018 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 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH-SERIES qemu-server/manager 0/7] VM CPU flags: introduce vendor-agnostic 'nested-virt' CPU flag 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: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" Am 06.11.25 um 6:14 PM schrieb Daniel Kral: > - setting e.g. `-vmx` in a custom model and `+nested-virt` in the VM's > cpu flags will result in: > > CPU flag 'nested-virt' resolved to 'vmx' > warning: CPU flag/setting '+vmx' (manually set for VM) overwrites > '-vmx' (set by custom CPU model) > > - but setting `-vmx` in the custom model and `-nested-virt` in the VM's > cpu flags will result in only: > > CPU flag 'nested-virt' resolved to 'vmx' > > The same happens vice versa with `+vmx` in the custom model and > `{+,-}nested-virt` in the VM's cpu flags. Well yes, this is part of the existing logic. Such a warning will only get logged if settings on different configuration levels are incompatible with each other. Note that the warning I added in the series is different and triggers only when both nested-virt and smv/vmx are defined on the same level of configuration. > From what I can figure this should also work with live migration, > because resolve_cpu_flags will be called at vm_start, right? My series does not change anything there. Between compatible models, it will work. Between incompatible models, for example one with the flag, one without or between different vendors, will not. But there is no early error and that is bad. We only pass along the running CPU during migration when a custom model is used, but not otherwise. I'll make sure to also pass it along if the nested-virt flag is used in v2! And I'll mention the caveat in the description to make sure people won't think this will magically make live migration between different vendors with nesting work or something. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel