In user emulation, threads -- implemented as CPU -- are
created/destroyed, but never reset. There is no point in
providing the sysemu/reset handlers there.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 hw/core/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/core/meson.build b/hw/core/meson.build
index 7a4d02b6c0..ce6fdb0064 100644
--- a/hw/core/meson.build
+++ b/hw/core/meson.build
@@ -3,7 +3,6 @@ hwcore_ss.add(files(
   'bus.c',
   'qdev-properties.c',
   'qdev.c',
-  'reset.c',
   'resettable.c',
   'vmstate-if.c',
   # irq.c needed for qdev GPIO handling:
@@ -15,6 +14,7 @@ if have_system
   hwcore_ss.add(files(
     'hotplug.c',
     'qdev-hotplug.c',
+    'reset.c',
   ))
 else
   hwcore_ss.add(files(
-- 
2.38.1

On Tue, 20 Dec 2022 at 14:56, Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>
> In user emulation, threads -- implemented as CPU -- are
> created/destroyed, but never reset. There is no point in
> providing the sysemu/reset handlers there.

We do reset the CPU, the linux-user code calls
cpu_reset() after creating it (and this is required for
correct behaviour). What we don't need (and what this patch
is making system-only) is the "register a global reset
function" API (which is non-functional in user-mode binaries
because nothing ever calls the qemu_devices_reset() function
to say "run all the hooks", so it makes sense not to compile
it in).

thanks
-- PMM