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 D9346C369D3 for ; Mon, 28 Apr 2025 11:08:18 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1u9ML4-0002o3-T1; Mon, 28 Apr 2025 07:07:54 -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 1u9ML2-0002kC-AV for qemu-devel@nongnu.org; Mon, 28 Apr 2025 07:07:52 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1u9MKv-0001Rc-2I for qemu-devel@nongnu.org; Mon, 28 Apr 2025 07:07:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1745838463; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=M1AOojelORdVeu6DgUmb9GePIy/ctN0iAgA8kDjVK+0=; b=RbtWV8YYl6MHGv+CUOIVgdsO4kyQcOccsSyIvwXmUQEehhMWabXeYYZ++x8+m0QkWyeiLD Uf3UYHVxuv0bj9YL2G5lWLot6yp7N7r1oce6d450c9+dEb5cfT5WhWkdek/t0dHbyp8bjH SDKPLERz5pyRU7QEc6Ib2lAUQrW4+0Y= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-690-E4rKltLZN1SffHMLvBW9og-1; Mon, 28 Apr 2025 07:07:37 -0400 X-MC-Unique: E4rKltLZN1SffHMLvBW9og-1 X-Mimecast-MFC-AGG-ID: E4rKltLZN1SffHMLvBW9og_1745838456 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 317BE195608C; Mon, 28 Apr 2025 11:07:36 +0000 (UTC) Received: from blackfin.pond.sub.org (unknown [10.45.242.27]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 9EBD730001A2; Mon, 28 Apr 2025 11:07:34 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 2C8EE21E66C2; Mon, 28 Apr 2025 13:07:32 +0200 (CEST) From: Markus Armbruster To: Peter Krempa Cc: Pierrick Bouvier , qemu-devel@nongnu.org, richard.henderson@linaro.org, stefanha@redhat.com, Michael Roth , pbonzini@redhat.com, peter.maydell@linaro.org, thuth@redhat.com, jsnow@redhat.com, philmd@linaro.org, Alex =?utf-8?Q?Benn=C3=A9e?= , devel@lists.libvirt.org Subject: Re: [RFC PATCH 0/3] single-binary: make QAPI generated files common In-Reply-To: (Peter Krempa's message of "Mon, 28 Apr 2025 10:55:34 +0200") References: <20250424183350.1798746-1-pierrick.bouvier@linaro.org> <87a584b69n.fsf@pond.sub.org> Date: Mon, 28 Apr 2025 13:07:32 +0200 Message-ID: <8734dswnm3.fsf@pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 Received-SPF: pass client-ip=170.10.133.124; envelope-from=armbru@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -35 X-Spam_score: -3.6 X-Spam_bar: --- X-Spam_report: (-3.6 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.492, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, 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 Peter Krempa writes: > On Fri, Apr 25, 2025 at 17:38:44 +0200, Markus Armbruster via Devel wrote: >> Pierrick Bouvier writes: > > [...] > >> To be precise: conditionals that use macros restricted to >> target-specific code, i.e. the ones poisoned by exec/poison.h. Let's >> call them target-specific QAPI conditionals. >> >> The QAPI generator is blissfully unaware of all this. >> >> The build system treats QAPI modules qapi/*-target.json as >> target-specific. The .c files generated for them are compiled per >> target. See qapi/meson.build. >> >> Only such target-specific modules can can use target-specific QAPI >> conditionals. Use in target-independent modules will generate C that >> won't compile. >> >> Poisoned macros used in qapi/*-target.json: >> >> CONFIG_KVM >> TARGET_ARM >> TARGET_I386 >> TARGET_LOONGARCH64 >> TARGET_MIPS >> TARGET_PPC >> TARGET_RISCV >> TARGET_S390X Commands and events: CPU introspection: query-cpu-model-baseline, query-cpu-model-comparison, query-cpu-model-expansion, query-cpu-definitions S390 KVM CPU stuff: set-cpu-topology, CPU_POLARIZATION_CHANGE, query-s390x-cpu-polarization. GIC: query-gic-capabilities SEV: query-sev, query-sev-launch-measure, query-sev-capabilities, sev-inject-launch-secret, query-sev-attestation-report SGX: query-sgx, query-sgx-capabilities Xen: xen-event-list, xen-event-inject An odd duck: rtc-reset-reinjection > I've had a look at what bits of the QMP schema are depending on the > above defines which libvirt uses. > > In many cases libvirt could restrict the use of given command/property > to only supported architectures. We decided to simply probe the presence > of the command because it's convenient to not have to filter them any > more > > - query-gic-capabilities > - libvirt already calls this only for ARM guests based on the > definition > > - query-sev and friends > - libvirt uses presence of 'query-sev' to decide if the binary > supports it; patching in a platofrm check is possible although > inconvenient > > - query-sgx and friends > - similar to sev > > -query-cpu-definitions and friends > - see below Large subset of my list. >> > What we try to do here is to build them only once >> instead. >> >> You're trying to eliminate target-specific QAPI conditionals. Correct? >> >> > In the past, we identied that the best approach to solve this is to expose code >> > for all targets (thus removing all #if clauses), and stub missing >> > symbols for concerned targets. >> >> This affects QAPI/QMP introspection, i.e. the value of query-qmp-schema. >> >> Management applications can no longer use introspection to find out >> whether target-specific things are available. > > Indeed and libvirt already uses this in few cases as noded above. > >> >> For instance, query-cpu-definitions is implemented for targets arm, >> i386, loongarch, mips, ppc, riscv, and s390x. It initially was for >> fewer targets, and more targets followed one by one. Still more may >> follow in the future. Right now, management applications can use >> introspection to find out whether it is available. That stops working >> when you make it available for all targets, stubbed out for the ones >> that don't (yet) implement it. >> >> Management applications may have to be adjusted for this. >> >> This is not an attempt to shoot down your approach. I'm merely >> demonstrating limitations of your promise "if anyone notices a >> difference, it will be a bug." >> >> Now, we could get really fancy and try to keep introspection the same by >> applying conditionals dynamically somehow. I.e. have the single binary >> return different introspection values depending on the actual guest's >> target. > > I wonder how this will work if libvirt is probing a binary. Libvirt does > not look at the filename. It can't because it can be a > user-specified/compiled binary, override script, or a distro that chose > to rename the binary. > > The second thing that libvirt does after 'query-version' is > 'query-target'. > > So what should libvirt do once multiple targets are supported? > > How do we query CPUs for each of the supported targets? > > Will the result be the same if we query them one at a time or all at > once? Pierrick's stated goal is to have no noticable differences between the single binary and the qemu-system- it covers. This is obviously impossible if we can interact with the single binary before the target is fixed. >> This requires fixing the target before introspection. Unless this is >> somehow completely transparent (wrapper scripts, or awful hacks based on >> the binary's filename, perhaps), management applications may have to be >> adjusted to actually do that. > > As noted filename will not work. Users can specify any filename and > create override scripts or rename the binary. True. >> Applies not just to introspection. Consider query-cpu-definitions >> again. It currently returns CPU definitions for *the* target. What >> would a single binary's query-cpu-definitions return? The CPU >> definitions for *all* its targets? Management applications then receive >> CPUs that won't work, which may upset them. To avoid noticable >> difference, we again have to fix the target before we look. > > Ah I see you had a similar question :D > >> >> Of course, "fixing the target" stops making sense once we move to >> heterogeneous machines with multiple targets. >> >> > This series build QAPI generated code once, by removing all TARGET_{arch} and >> > CONFIG_KVM clauses. What it does *not* at the moment is: >> > - prevent target specific commands to be visible for all targets >> > (see TODO comment on patch 2 explaining how to address this) >> > - nothing was done to hide all this from generated documentation