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 E370DC5DF97 for ; Wed, 26 Aug 2026 12:33:40 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1wzCor-0007tp-Rh; Wed, 26 Aug 2026 08:33:29 -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 1wzCor-0007tX-1Z for qemu-arm@nongnu.org; Wed, 26 Aug 2026 08:33:29 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wzCop-00043R-2q for qemu-arm@nongnu.org; Wed, 26 Aug 2026 08:33:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1787747605; h=from:from:reply-to: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=3IZbLtMK+eaeWJqSopYckXC2Rifx6mwRmusak3iCl3k=; b=XrA4C0xaIYNxLYlH/TSWkX5WS6CpL48E1q4vQBk5kgdq+SazkmUWO3b9fxEF73jTT27DuR t5nTSltcgOs9YD4JcI4oPjdfQ8y+blWGmAjg4Sdb/5hqk/LSClmRySMgxiAHXgFJUuIu3i UV8PDr9S3K851gDgktjAxWkzA4D4LyI= 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-279-oqGOJo7BOWuwHfujpyszow-1; Wed, 26 Aug 2026 08:33:20 -0400 X-MC-Unique: oqGOJo7BOWuwHfujpyszow-1 X-Mimecast-MFC-AGG-ID: oqGOJo7BOWuwHfujpyszow_1787747592 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (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 9320119560A5; Wed, 26 Aug 2026 12:33:11 +0000 (UTC) Received: from redhat.com (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id AFFCB1955F05; Wed, 26 Aug 2026 12:32:59 +0000 (UTC) Date: Wed, 26 Aug 2026 13:32:56 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Yonggang Luo Cc: qemu-devel@nongnu.org, Xianglai Li , Alistair Francis , Chinmay Rath , Sunil V L , qemu-riscv@nongnu.org, Alexander Bulekov , Zhao Liu , Eric Farman , Laurent Vivier , Peter Maydell , Chao Liu , Liu Zhiwei , Palmer Dabbelt , Song Gao <17746591750@163.com>, Harsh Prateek Bora , Glenn Miles , Daniel Henrique Barboza , Pierrick Bouvier , qemu-s390x@nongnu.org, Jiaxun Yang , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , "Michael S. Tsirkin" , Stefan Hajnoczi , Alex =?utf-8?Q?Benn=C3=A9e?= , David Hildenbrand , qemu-ppc@nongnu.org, qemu-arm@nongnu.org, Igor Mammedov , Aleksandar Rikalo , Nicholas Piggin , Cornelia Huck , Richard Henderson , Ilya Leoshkevich , Fabiano Rosas , Aurelien Jarno , Paolo Bonzini , Ani Sinha , Bibo Mao , =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , Matthew Rosato , Weiwei Li , Darren Kenny Subject: Re: [PATCH 00/12] single-binary: link ARM and RISC-V into qemu-system Message-ID: References: <20260823150731.896-1-luoyonggang@gmail.com> MIME-Version: 1.0 In-Reply-To: <20260823150731.896-1-luoyonggang@gmail.com> User-Agent: Mutt/2.4.0 (2026-06-19) X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 X-Mimecast-MFC-PROC-ID: iMEx_SJOyArVTiYaAkkqfmLfO0S8TZjRrIiXjREuVkQ_1787747592 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Received-SPF: pass client-ip=170.10.129.124; envelope-from=berrange@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_H2=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-arm@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Errors-To: qemu-arm-bounces+qemu-arm=archiver.kernel.org@nongnu.org Sender: qemu-arm-bounces+qemu-arm=archiver.kernel.org@nongnu.org On Sun, Aug 23, 2026 at 11:07:18PM +0800, Yonggang Luo wrote: snip, ..to comment just on the end result for now.. > The last patch builds qemu-system (and qemu-systemw on Windows) from > aarch64 common/system objects plus RISC-V arch objects, and installs > qemu-system-{arm,aarch64,riscv32,riscv64} as symlinks so argv[0] still > selects TargetInfo. > > Examples: > > qemu-system -target aarch64 -M virt ... > qemu-system-riscv64 -M virt ... > > A basename that matches no registered token falls through to the unique > default. A combined binary with no suffix requires -target when more > than one default TargetInfo is registered. In testing and comparing the new qemu-system-riscv64 symlink to qemu-system vs the current standalone qemu-system-riscv64 binary there are some significant user visible changes. The simplest is 'qom-list-types' went from reporting approx 770 classes, to reporting approx 1530 classes. IOW, the qemu-system-riscv64 binary is now reporting supporting for all the classes that were unique to arm. The '-device help' output similarly shows a great many more devices TL;DR introspecting qemu-system-riscv64 is no longer accurate wrt riscv64 capabilities. This is not suprising, since we register all TypeInfo meaning we get all QOM classes present. Some of Pierricks patches try to filter places which iterate over classes, but this does not have full coverage. I think this is probably also what leads to the increased RAM usage in qemu-system-riscv64. Starting qemu-system-riscv64 -nodefaults -display none -M none shows an increase in RAM usage from 17.3 to 20.7 MB which is about 15% increase. NB this is dirty, private RAM per process. The shared RAM pages also increase but that's not a concern since they're common to all QEMU processes. qemu-system-aarch64 shows a much smaller RAM increase, since it only grew from 1430 classes to 1530 classes. We have many more target though, so if we assume the end point where every single target is unified, the the union of all classes for all targets comes to approx 3600. My guesstimate is that would mean a memory increase for qemu-system-riscv64 from 17.3 to 39.9 MB, which is a 72% increase. In absolute terms this is still modest, but for deployments with large VM counts and small RAM sizes, that gets to be significant. None of this means single binary is a bad idea. My main takeaway is that we're creating uneccessary work for ourselves by trying to make 'qemu-sytem' identical in behaviour to qemu-system-$TARGET. The complex filtering patches / QOM interfaces that I found uncomfortable in Pierrick's base series are largely around the filtering needed to simulate qemu-system-$TARGET, and they're still incomplete. I don't have high confidence in our ability to avoid regressions if we go route this route. IMHO we should make a clean break with the past. Leave the existing qemu-system-$TARGET binaries being built from the same pieces they are today, such that there is better confidence that we are not making behavioural changes to them. qemu-system should be built alongside qemu-system-$TARGET and offer new semantics where it is documented as exposing everything from all targets whenever introspected and does not apply target type or target Kconfig filtering to inputs/ outputs. We still get the benefit of only building most .o files once, so keeping qemu-system-$TARGET is only a small overhead in the final step of linking everything together. qemu-system will still have the increased memory overhead but that's fine as qemu-system-$TARGET will be unaffected. We can tackle the memory overhead of qemu-system at our leisure through use of loadable modules, and thus not have that as a task to think about today. With the clean break with the past, we also have the ability to tackle various long standing design mistakes present in qemu-system-$TARGET instead of carrying them over into the new binary. Specifically * -nodefaults should become the default * All CLI args should be processed in order from the command line, so we eliminate the nonsense where we process some -object, then -chardev, then more -object through hand crafted deps * No default machine type * Drop all legacy syntax so we only have a single QAPI based way of configuring. eg drop -hda, -hdb, -cdrom, -drive, etc only keeping -blockdev eg drop -mon, -monitor, -qmp, etc only keeping -object We don't have to do all that straightaway. If we declare qemu-system "experimental" initially we can iterate on that intentionally breaking compat in releases, without any impact on qemu-system-$TARGET. Avoiding the back compat task will give us more flexibility with the follow on work when people come to create new machine types with heterogenous CPU targets. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|