From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <pve-devel-bounces@lists.proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 0337D1FF16B for <inbox@lore.proxmox.com>; Thu, 6 Mar 2025 13:56:10 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id B507165A8; Thu, 6 Mar 2025 13:56:03 +0100 (CET) Message-ID: <02f3ba81-41a4-4f92-a955-067d196ef489@proxmox.com> Date: Thu, 6 Mar 2025 13:55:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Dominik Csapak <d.csapak@proxmox.com>, Proxmox VE development discussion <pve-devel@lists.proxmox.com> References: <20250306104459.1272297-1-d.csapak@proxmox.com> <20250306104459.1272297-3-d.csapak@proxmox.com> <0e5bf049-0f93-423f-b1b2-c14617f3fb40@proxmox.com> <bf081277-b97e-4bcf-b90f-8737e873d038@proxmox.com> Content-Language: en-US From: Fiona Ebner <f.ebner@proxmox.com> In-Reply-To: <bf081277-b97e-4bcf-b90f-8737e873d038@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL -0.042 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 qemu-server 2/8] config to command: add one '-global' option for each flag X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com> Am 06.03.25 um 13:15 schrieb Dominik Csapak: > On 3/6/25 13:13, Fiona Ebner wrote: >> Am 06.03.25 um 11:44 schrieb Dominik Csapak: >>> If we have multiple 'globalFlags', we have to encode each one separately >>> on the commandline with '-global OPTION', since QEMU does not allow to >>> have multiple options here. >>> >>> We currently only have one such flag that used the 'globalFlags' list, >>> so it never popped up. (All other uses directly add an option to the >>> commandline) >>> >>> Avoid future bugs by fixing it now. >>> >> >> So there is no real point to collecting the flags in the first place? >> I.e. we could also get rid of the variable and have the single current >> user of the variable add the flag directly on the commandline too. Or >> otherwise, we could change the other users and collect all flags with >> this variable. Pre-existing of course, but ideally, we could avoid the >> mishmash. >> > > Sorry this could have been more clear here: > I add to the flags in one of the following patches, so i sent this > in preparation of that (could possibly be squashed) Yes, I understand that. I still think the status quo with mixing two different approaches might not be best. It's not going to be a blocker for the series, but I wanted to mention it, if you want to go for avoiding it. > I did not want to touch the other places, since that in turn changes > the order of the qemu commandline (which sometimes has unintended side > effects, e.g. in combination with the 'args' parameter) Are you sure? Custom 'args' are always added last so that shouldn't matter. The only thing that would change by removing the global flags variable is having "-global kvm-pit.lost_tick_policy=discard" earlier in the commandline. I think that should be fine. In particular QEMU's qemu_init() function has a call to user_register_global_props() which handles all global properties at the same time, so I think changing the order should be fine in (almost?) all cases. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel