From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AD450C3ABBE for ; Thu, 8 May 2025 08:27:43 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1uCwaV-0006Vg-3S; Thu, 08 May 2025 04:26:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uCwaT-0006SZ-Co for qemu-devel@nongnu.org; Thu, 08 May 2025 04:26:37 -0400 Received: from mgamail.intel.com ([198.175.65.13]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uCwaP-0007gM-UG for qemu-devel@nongnu.org; Thu, 08 May 2025 04:26:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1746692794; x=1778228794; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=j9w5RAXLNqtonoshyUaBzo7N5QRsOFAt4LXyfk5+g+I=; b=kQ4M1q5wVgl0yg/LQV9KrYaQq4FMCrAHtrYKsgHLtMA+r2ABTkuJVFX9 d2Cu+J9NtyFhb4sBWU63eiLXJdxfel3GJNpWyABuBkpYMZgd0hjalf35k u585WP6DFZlIW1FDB3vgv98Ez5B5VzQFapQfe5aQeDbVjFT3wfekCQWuI YgjRMIK03GEY00C8jv17YONM/NXK9YPfFLy5DFDPwdffsNdcTpH+nR3bi m2TcHdFVJN5qGOKIERSiCYzgBTdsMUMrIZ+kEsiBw1TqOpqyP3UDAsz3M f5RM1HsON6wlxqQsu0beBq3vaRX24p7Jl/wbQyzGQfOoF4v8VG6p6i7yH A==; X-CSE-ConnectionGUID: rqnND+NuTXidxkQ8s2DqIw== X-CSE-MsgGUID: pCf+L3CYQ3CA9rmfgXDgnA== X-IronPort-AV: E=McAfee;i="6700,10204,11426"; a="59449480" X-IronPort-AV: E=Sophos;i="6.15,271,1739865600"; d="scan'208";a="59449480" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 May 2025 01:26:29 -0700 X-CSE-ConnectionGUID: MgDNbu7aRKC2J+PMs/bmLA== X-CSE-MsgGUID: 14H8LvYUSZicaY97HJYKnw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.15,271,1739865600"; d="scan'208";a="140257621" Received: from liuzhao-optiplex-7080.sh.intel.com (HELO localhost) ([10.239.160.39]) by fmviesa003.fm.intel.com with ESMTP; 08 May 2025 01:26:19 -0700 Date: Thu, 8 May 2025 16:47:21 +0800 From: Zhao Liu To: Markus Armbruster Cc: Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= , Paolo Bonzini , Alex =?iso-8859-1?Q?Benn=E9e?= , Mark Burton , Eduardo Habkost , Alessandro Di Federico , Alistair Francis , Anton Johansson , Brian Cain , "Daniel P. Berrange" , Chao Peng , Neo Jia , =?iso-8859-1?Q?C=E9dric?= Le Goater , "Wedgwood, Chris" , dhedde@kalrayinc.com, Eric Blake , eblot@rivosinc.com, "Edgar E. Iglesias" , Elena Ufimtseva , Auger Eric , Felipe Franciosi , iggy@theiggy.com, Warner Losh , Jan Kiszka , Jason Gunthorpe , Jidong Xiao , Jim Shu , Joao Martins , Konrad Rzeszutek Wilk , Luc Michel , Manos Pitsidianakis , Max Chou , Meirav Dean , mimu@linux.vnet.ibm.com, "Ho, Nelson" , Paul Walmsley , Peter Maydell , QEMU Developers , Roberto Campesato , Richard Henderson , Shameerali Kolothum Thodi , Bernhard Beschow , Stefan Hajnoczi , Thomas Huth , Wei Wang , z.huo@139.com, LIU Zhiwei , "Wu, Zhiyong" Subject: Re: KVM/QEMU Community call 29/04/2025 agenda items? Message-ID: References: <874iy85yx2.fsf@draig.linaro.org> <87a57ydj8y.fsf@pond.sub.org> <5ce00003-4105-40c7-954b-63336a4325d5@linaro.org> <87plgkihg4.fsf@pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87plgkihg4.fsf@pond.sub.org> Received-SPF: pass client-ip=198.175.65.13; envelope-from=zhao1.liu@intel.com; helo=mgamail.intel.com X-Spam_score_int: -57 X-Spam_score: -5.8 X-Spam_bar: ----- X-Spam_report: (-5.8 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.414, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org On Wed, May 07, 2025 at 05:11:39PM +0200, Markus Armbruster wrote: > Date: Wed, 07 May 2025 17:11:39 +0200 > From: Markus Armbruster > Subject: Re: KVM/QEMU Community call 29/04/2025 agenda items? > > Philippe Mathieu-Daudé writes: > > > On 30/4/25 12:41, Markus Armbruster wrote: > > [...] > > >> Pierrick's stated goal is to have no noticable differences between the > >> single binary and the qemu-system- it covers. > >> > >> We have two external interfaces to worry about: QMP and the command > >> line. Let's ignore the latter for now. > >> > >> Target-specific differences in *syntax* come from QAPI schema > >> conditionals with target-specific conditions. Example: > >> > >> { 'command': 'query-cpu-definitions', 'returns': ['CpuDefinitionInfo'], > >> 'if': { 'any': [ 'TARGET_PPC', > >> 'TARGET_ARM', > >> 'TARGET_I386', > >> 'TARGET_S390X', > >> 'TARGET_MIPS', > >> 'TARGET_LOONGARCH64', > >> 'TARGET_RISCV' ] } } > >> > >> This command is only defined for some targets. > >> > >> The value of query-qmp-schema reflects this: it has > >> query-cpu-definitions exactly when the condition is satisfied. The > >> condition is evaluated at compile-time, because that's how QAPI schema > >> 'if' works. > >> > >> Say we drop the condition and instead add an equivalent run-time > >> condition to command registration. This preserves behavior of command > >> execution. But query-qmp-schema now has query-cpu-definitions *always*. > >> This is a noticable difference. It may break management applications > >> that use query-qmp-schema to probe for the command. > >> > >> Moreover, conditionals aren't limited to commands. Example: > >> > >> { 'struct': 'CpuModelExpansionInfo', > >> 'data': { 'model': 'CpuModelInfo', > >> 'deprecated-props' : { 'type': ['str'], > >> ---> 'if': 'TARGET_S390X' } }, > >> 'if': { 'any': [ 'TARGET_S390X', > >> 'TARGET_I386', > >> 'TARGET_ARM', > >> 'TARGET_LOONGARCH64', > >> 'TARGET_RISCV' ] } } > >> > >> Here we have a conditional member. > > [...] > > > IMHO conditionals should only depend on host / static configuration > > features, not features modifiable from the command line. > > This is how the QAPI schema works now. > > > (I'm always > > confused by KVM features published in the schema, but then you start > > your binary with -accel=tcg and still can run KVM specific commands > > via QMP, returning errors). > > Not exactly a ringing endorsement for keeping the QAPI schema work the > way it does now, isn't it? ;) > > The problem at hand is QAPI-generated files in a single binary. > > Pierrick posted "[RFC PATCH 0/3] single-binary: make QAPI generated > files common". The patches are flawed, but that's alright for RFC. > > In review, I pointed out three possible solutions, and discussed their > pros and cons: > > (1) Drop target-specific conditionals. > > (2) Replace them by run-time checks. > > (3) Have target-specific QAPI-generated code for multiple targets > coexist in the single binary. Thank you Markus for your nice summary! I also apologize to you and Philippe if I didn't understand correctly (I tried to look at Pierrick's and Philippe's work, but still worry about I may have wrong understanding :-) ) > Both (1) and (3) keep the QAPI schema work as it does now. > > Pierrick's patches are an incomplete attempt at (2). I see. > Daniel made a case for (1). You and I actually discussed (1) before, > and I encouraged you to explore it. And I notice Philippe has 2 patches: (1) For QAPI, this is to drop target-specific cond: https://lore.kernel.org/qemu-devel/20250429100419.20427-1-philmd@linaro.org/ I feel it's a smart way to make it optional. (2) Not for QAPI, but this is try to add runtime check: https://lore.kernel.org/qemu-devel/20250502214551.80401-5-philmd@linaro.org/ I am thinking about how kvm-pmu-filter could be aligned with these current efforts in mail list. I can drop all the target conditions for KvmPmuEventFormat: { 'enum': 'KvmPmuEventFormat', 'data': ['raw', 'x86-select-umask', 'x86-masked-entry'] } This is what you listed before and it is similar to the way in (1). But only (1) is not enough because I can't make these formats as optional (pls educate me if I'm wrong :-) ). Therefore, I think I need run-time check like Philippe did in (2), in my kvm-pmu.c file. Do you think so? An additional question - about CONFIG_KVM - is that I see that it's all currently focused on solving target-specific problems, and I understand that it's not yet kvm-specific's turn. But kvm-pmu-filter does (or, may :-) ) need CONFIG_KVM. My initial thought is, is it possible to remove the CONFIG_KVM condition for kvm-pmu-filter in QAPI and use the same runtime check? But this would require accel-info as Philippe's work on target-info in [2]). > We can certainly discuss this some more, but I'd prefer to review a > working solution instead. With so many options on the table, I'm a bit confused about the fate of kvm-pmu-filter. Should this case wait for the most appropriate option to come along, or could it move forward based on the status quo, and then consider the refactoring later with the final optimal option? Regards, Zhao