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 lists1p.gnu.org (lists1p.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 1408CC624DE for ; Fri, 4 Sep 2026 11:25:50 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x2S35-00023H-Ch; Fri, 04 Sep 2026 07:25:35 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x2S33-000234-SH for qemu-devel@nongnu.org; Fri, 04 Sep 2026 07:25:33 -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 1x2S32-0004i0-03 for qemu-devel@nongnu.org; Fri, 04 Sep 2026 07:25:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1788521130; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8wYo7RAxuQlL+CBByj9Y3gBTTEJHMxoIDPCcgOZ8Ujg=; b=iB28aqdwPc+LLJnNKo6KxLfr2CaCZrX9UdEIfy9f+cxY4JaQt5z9XRp4oXe/Yir7lQY/Hn /i4TrHhhhlVUao4Pa/DabOGRRzInBmO/sUKKbOaKcMHT15cg+94P7Mf4gfURYsQSBhLI/q 087UabQ5OFk8KdDAlGmwcDzZxfvv9oE= Received: from mx-prod-mc-03.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-226-B3SXVC1qPmur_c3ws2M7Yw-1; Fri, 04 Sep 2026 07:25:27 -0400 X-MC-Unique: B3SXVC1qPmur_c3ws2M7Yw-1 X-Mimecast-MFC-AGG-ID: B3SXVC1qPmur_c3ws2M7Yw_1788521126 Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (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-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 19EB61925776; Fri, 4 Sep 2026 11:25:26 +0000 (UTC) Received: from blackfin.pond.sub.org (unknown [10.44.22.5]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id B058E1955F70; Fri, 4 Sep 2026 11:25:25 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 40E7E21E6A04; Fri, 04 Sep 2026 13:25:23 +0200 (CEST) From: Markus Armbruster To: Daniel P. =?utf-8?Q?Berrang=C3=A9?= Cc: Yonggang Luo , Pierrick Bouvier , qemu-devel@nongnu.org, anjo@rev.ng, Daniel Henrique Barboza , philmd@oss.qualcomm.com, Peter Maydell , Paolo Bonzini , Richard Henderson Subject: Re: [PATCH 00/47] single-binary: implement dynamic filtering for QOM types In-Reply-To: ("Daniel P. =?utf-8?Q?Berrang?= =?utf-8?Q?=C3=A9=22's?= message of "Fri, 4 Sep 2026 10:45:47 +0100") References: <20260828225901.367438-1-pierrick.bouvier@oss.qualcomm.com> <4b4f77ee-21e9-405e-a1da-21506afa1c5b@oss.qualcomm.com> Date: Fri, 04 Sep 2026 13:25:23 +0200 Message-ID: <878q5h8di4.fsf@pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 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: 12 X-Spam_score: 1.2 X-Spam_bar: + X-Spam_report: (1.2 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_SBL_CSS=3.335, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: qemu development 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 Daniel P. Berrang=C3=A9 writes: > On Fri, Sep 04, 2026 at 04:58:10PM +0800, Yonggang Luo wrote: >> Device filtering would be complicated, I guess, as there is so much >> CONFIG_* for devices. Another approach is to just place devices under an >> meson "enable_modules " (in *.so/*.dll/*.dylib), so it won't be >> listed(memory consumption will also be reduced when it's not needed). > > While modules are important for reducing memory consumption, I don't think > they need to be a blocker - making more things into modules can be done > in the backaround as & when people want to work on it. I fear modules need serious work to before we can use them more widely. I described issues in Subject: Dynamic & heterogeneous machines, initial configuration: probl= ems Date: Wed, 31 Jan 2024 21:14:21 +0100 Message-ID: <87o7d1i7ky.fsf@pond.sub.org> https://lore.kernel.org/qemu-devel/87o7d1i7ky.fsf@pond.sub.org/ Copy of relevant part: =3D Problem 3: Loadable modules =3D QOM wasn't designed for loadable modules. Support for them was grafted on, and there are serious deficiencies. Building a loadable module results in a DSO. Additionally, module meta-data necessary to load it is compiled into the executables that can load modules. Actually loading a module can fail, e.g. when the module was not deployed. Loadable modules are designed to be transparent, i.e. users don't need to know whether a module is compiled in or loadable. QOM types don't exist until the module is initialized. Compiled-in modules are initialized early in startup. Loadable modules are initialized on load. QMP command qom-list-types returns all QOM types. To be able to find them all, it needs to load all modules. Modules that cannot be found (or have dependencies that cannot be found) are silently ignored. Any other loading errors are reported to stderr with error_report_err(), which is inappropriate. In either case, the types provided by the unloadable modules are not returned by the command. We have two functions to look up an object class by name: object_class_by_name() and module_object_class_by_name(). The latter attempts to load a module when the type doesn't exist. Again, modules that cannot be found are silently ignored, and other loading errors are reported with error_report_err(), which is inappropriate in certain contexts. When to use which of the two functions is unclear. Existing usage may well be wrong. The QOM functions to create objects in-place (object_initialize(), ...) or on the heap (object_new(), ...) cannot fail. This is just fine in QOM's original design. It is not fine when a loadable module fails to load. Since the functions can't fail, they exit(1) then. This means things like a hot plugging a device provided by a loadable module can crash a VM immediately. Attempting to load all modules beforehand with qom-list-types does not protect against this: we try to load again, fail again, and exit(1).