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 5EFF6770FB for ; Thu, 21 Oct 2021 11:56:06 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 5C1321C440 for ; Thu, 21 Oct 2021 11:56:06 +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 id 5BC5E1C435 for ; Thu, 21 Oct 2021 11:56:05 +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 341A9423F1 for ; Thu, 21 Oct 2021 11:56:05 +0200 (CEST) To: Thomas Lamprecht , Proxmox VE development discussion References: <20211021083609.2057094-1-t.lamprecht@proxmox.com> <84082700-e83c-1057-f5cb-a1e35b41f4fa@proxmox.com> From: Stefan Reiter Message-ID: <385c4810-af7e-15de-cf79-263c8804ec2b@proxmox.com> Date: Thu, 21 Oct 2021 11:56:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <84082700-e83c-1057-f5cb-a1e35b41f4fa@proxmox.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 1.610 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -2.267 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 Subject: Re: [pve-devel] [PATCH 0/4] add meta info and bandaid for QEMU 6.1 and unpinned q35 machine backward compat 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, 21 Oct 2021 09:56:06 -0000 On 10/21/21 11:47 AM, Thomas Lamprecht wrote: > On 21.10.21 11:34, Stefan Reiter wrote: >> On 10/21/21 10:36 AM, Thomas Lamprecht wrote: >>> First add a new meta property that is currently exclusively set on new >>> VM creation and then read-only, initially add the creation time as UNIX >>> epoch and the QEMU version that was installed during installation >>> (thought about using the one on first start but that actually does not >>> gives any more guarantee, so just go for simple). >>> >>> Use that information to band aid around a change regarding hotplug in >>> QEMU 6.1 that can affected older VMs on fresh start (migration and >>> rollback is covered by force-machine mechanisms as always already). >>> >>> I'm not 100% convinced of the whole thing, albeit I see some merit in >>> the meta property even if we do not go with the last patch, anyhow, I >>> proposed this off-list to Dominik (and those thing is partly his idea >>> too), Wolfgang, Fabian and Stefan and none of them rejected the idea nor >>> communicated a better/more preferred alternative, so I went for it >>> (still not steaming from enthusiasm though) >> >> So we're doing all of this to avoid issues with older VMs that expect >> "acpi-pci-hotplug-with-bridge-support=off" on Q35 (previously default), >> but we still want to set it for new VMs that are created with QEMU 6.1 >> and never booted with anything older. >> >> But taking a step back, do we actually want the new ACPI hotplug in >> general? If we choose to simply leave it be, we could just always add >> "acpi-pci-hotplug-with-bridge-support=off" to Q35 on QEMU > 6.1. >> Since it's a global property, I think we wouldn't even need to check >> machine-type/forcemachine at all, since we'd only make the default >> explicit with older ones. > > Check the commit I linked in patch 4/4, the change has some value. > > https://gitlab.com/qemu-project/qemu/-/commit/17858a1695 > I did read it, and I agree it has some improvements, was just wondering if it was worth our effort here (never encountered any of the described bugs or saw a user that encountered them anywhere). But I don't think this series is as bad as you make it out to be either ;)