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 3EB101FF15C for ; Fri, 14 Nov 2025 15:26:22 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 7DDB814E24; Fri, 14 Nov 2025 15:27:16 +0100 (CET) Message-ID: <91e9fb43-5ee3-4de2-a866-312d700e9fbe@proxmox.com> Date: Fri, 14 Nov 2025 15:27:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Thomas Lamprecht , pve-devel@lists.proxmox.com References: <20251107144429.126790-1-f.ebner@proxmox.com> <176307427734.2950096.5784486951090117457.b4-ty@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: <176307427734.2950096.5784486951090117457.b4-ty@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1763130407108 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.017 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 URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com] Subject: Re: [pve-devel] partially-applied: [PATCH-SERIES qemu-server/manager v2 0/8] 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 13.11.25 um 11:53 PM schrieb Thomas Lamprecht: > On Fri, 07 Nov 2025 15:43:38 +0100, Fiona Ebner wrote: >> Changes in v2 (thanks Dano and Thomas!): >> * Pass running CPU configuration when using 'nested-virt'. This >> ensures that migration fails early if the flag resolves differently >> on the target. >> * Describe that live migration still only works if it's the same flag. >> * Drop adding non-existing link in API end point. >> * Keep $supported_cpu_flags private to module and add getter method. >> * Unpack @_ first at the beginning of resolve_cpu_flags(). >> * ui: fix function call in the CPU flag selector widget. >> * ui: use simpler method to get all records of the store. >> * Drop already applied patches. >> >> [...] > > Applied the first three qemu-server patches already, thanks! > > For the nested-flag I'm not fully sure yet if this is enough also for Windows > guests to run e.g. WSL with a non-host CPU type like x86-64-v3, which I might > not put into scope originally, but for many users it will IMO be assumed as > "has to work" if we put this in the changelog. Thanks to Mario for directing my attention to the related bugzilla entry [0] earlier today! What seems to be necessary is setting the base model to something matching the vendor of the host CPU "cpu: EPYC,flags=+nested-virt" resulting in EPYC,enforce,hv_ipi,hv_relaxed,hv_reset,hv_runtime,hv_spinlocks=0x1fff,hv_stimer,hv_synic,hv_time,hv_vapic,hv_vpindex,+kvm_pv_eoi,+kvm_pv_unhalt,+svm,vendor=AuthenticAMD on the QEMU commandline. Well, I still got an error later: PS C:\Windows\system32> wsl -d archlinux wsl: Nested virtualization is not supported on this machine. but I also got a bash and could issue commands. FWIW, I got the same error and behavior when using "host" CPU model. I couldn't get it to work with CPU type qemu64, even with all of: qemu64,+abm,+aes,+avx,+avx2,+bmi1,+bmi2,enforce,+f16c,+fma,hv_ipi,hv_relaxed,hv_reset,hv_runtime,hv_spinlocks=0x1fff,hv_stimer,hv_synic,hv_time,hv_vapic,hv_vpindex,+kvm_pv_eoi,+kvm_pv_unhalt,+movbe,+pni,+popcnt,+sse4.1,+sse4.2,+ssse3,+xsave,+svm,hv_emsr_bitmap,hv_syndbg,hv_tlbflush,hv_tlbflush_direct,hv_tlbflush_ext,hv_xmm_input, kvm=off,vendor=AuthenticAMD,hv-passthrough Should we add a hint in the UI (if OS type is Windows) that the 'nested-virt' flag may require a base model matching the vendor of the host CPU? [0]: https://bugzilla.proxmox.com/show_bug.cgi?id=7021 _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel