-device T,help crashes

-device T,help crashes

[Markus Armbruster]

Watch this:

    $ qemu-system-aarch64 -S -display none -M virt -device acpi-ged,help
    qemu-system-aarch64: ../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.

A number of devices crash this way:

* acpi-ged (aarch64 arm i386 loongarch64 x86_64)
* fsl-imx6 (aarch64 arm)
* fsl-imx7 (aarch64 arm)
* fsl-imx8mp (aarch64)
* microchip.pfsoc (riscv64)
* riscv.sifive.e.soc (riscv32 riscv64)
* xlnx-zynqmp (aarch64)

Here's another one:

    $ qemu-system-sparc64 -S -display none -M virt -device sun4u-iommu,help
    qemu-system-sparc64: ../system/physmem.c:1401: register_multipage: Assertion `num_pages' failed.

Devices crashing this way:

* Loongson-3A4000-mips64-cpu (mips64 mips64el)
* dc232b-xtensa-cpu (xtensa)
* dc233c-xtensa-cpu (xtensa)
* de212-xtensa-cpu (xtensa)
* de233_fpu-xtensa-cpu (xtensa)
* dsp3400-xtensa-cpu (xtensa)
* fsf-xtensa-cpu (xtensaeb)
* lx106-xtensa-cpu (xtensa)
* sample_controller-xtensa-cpu (xtensa)
* sun4m-iommu (sparc)
* sun4u-iommu (sparc64)
* test_kc705_be-xtensa-cpu (xtensaeb)
* test_mmuhifi_c3-xtensa-cpu (xtensa)

These crashes escape tests/qtest/device-introspect-test, because it
covers only HMP "device_add T,help", not CLI "-device T,help".

Re: -device T,help crashes

[Peter Maydell]

On Wed, 11 Mar 2026 at 14:10, Markus Armbruster <armbru@redhat.com> wrote:
>
> Watch this:
>
>     $ qemu-system-aarch64 -S -display none -M virt -device acpi-ged,help
>     qemu-system-aarch64: ../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.
>
> A number of devices crash this way:
>
> * acpi-ged (aarch64 arm i386 loongarch64 x86_64)
> * fsl-imx6 (aarch64 arm)
> * fsl-imx7 (aarch64 arm)
> * fsl-imx8mp (aarch64)
> * microchip.pfsoc (riscv64)
> * riscv.sifive.e.soc (riscv32 riscv64)
> * xlnx-zynqmp (aarch64)

Largely speaking these are pretty useless to try to create on
the command line, of course...

-- PMM

Re: -device T,help crashes

[Thomas Huth]

On 11/03/2026 15.55, Peter Maydell wrote:
> On Wed, 11 Mar 2026 at 14:10, Markus Armbruster <armbru@redhat.com> wrote:
>>
>> Watch this:
>>
>>      $ qemu-system-aarch64 -S -display none -M virt -device acpi-ged,help
>>      qemu-system-aarch64: ../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.
>>
>> A number of devices crash this way:
>>
>> * acpi-ged (aarch64 arm i386 loongarch64 x86_64)
>> * fsl-imx6 (aarch64 arm)
>> * fsl-imx7 (aarch64 arm)
>> * fsl-imx8mp (aarch64)
>> * microchip.pfsoc (riscv64)
>> * riscv.sifive.e.soc (riscv32 riscv64)
>> * xlnx-zynqmp (aarch64)
> 
> Largely speaking these are pretty useless to try to create on
> the command line, of course...

Agreed, but note that you can also query help for non-user-creatable devices 
normally, e.g.:

$ ./qemu-system-x86_64 -device port92
qemu-system-x86_64: -device port92: Parameter 'driver' expects a pluggable 
device type
$ ./qemu-system-x86_64 -device port92,help
port92 options:
   a20[0]=<link<irq>>
   port92[0]=<child<memory-region>>

... so we likely should fix the crashes anyway, even if we decide to mark 
the devices with user_creatable = false.

  Thomas

Re: -device T,help crashes

[BALATON Zoltan]

On Wed, 11 Mar 2026, Markus Armbruster wrote:
> Watch this:
>
>    $ qemu-system-aarch64 -S -display none -M virt -device acpi-ged,help
>    qemu-system-aarch64: ../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.
>
> A number of devices crash this way:
>
> * acpi-ged (aarch64 arm i386 loongarch64 x86_64)
> * fsl-imx6 (aarch64 arm)
> * fsl-imx7 (aarch64 arm)
> * fsl-imx8mp (aarch64)
> * microchip.pfsoc (riscv64)
> * riscv.sifive.e.soc (riscv32 riscv64)
> * xlnx-zynqmp (aarch64)
>
> Here's another one:
>
>    $ qemu-system-sparc64 -S -display none -M virt -device sun4u-iommu,help
>    qemu-system-sparc64: ../system/physmem.c:1401: register_multipage: Assertion `num_pages' failed.
>
> Devices crashing this way:
>
> * Loongson-3A4000-mips64-cpu (mips64 mips64el)
> * dc232b-xtensa-cpu (xtensa)
> * dc233c-xtensa-cpu (xtensa)
> * de212-xtensa-cpu (xtensa)
> * de233_fpu-xtensa-cpu (xtensa)
> * dsp3400-xtensa-cpu (xtensa)
> * fsf-xtensa-cpu (xtensaeb)
> * lx106-xtensa-cpu (xtensa)
> * sample_controller-xtensa-cpu (xtensa)
> * sun4m-iommu (sparc)
> * sun4u-iommu (sparc64)
> * test_kc705_be-xtensa-cpu (xtensaeb)
> * test_mmuhifi_c3-xtensa-cpu (xtensa)
>
> These crashes escape tests/qtest/device-introspect-test, because it
> covers only HMP "device_add T,help", not CLI "-device T,help".

Maybe these should be user_creatable=false in the first place as they 
look like some internal devices used to model a SoC or machine specific 
stuff.

Regards,
BALATON Zoltan

Re: -device T,help crashes

[Markus Armbruster]

Thomas Huth <thuth@redhat.com> writes:

> On 11/03/2026 15.55, Peter Maydell wrote:
>> On Wed, 11 Mar 2026 at 14:10, Markus Armbruster <armbru@redhat.com> wrote:
>>>
>>> Watch this:
>>>
>>>      $ qemu-system-aarch64 -S -display none -M virt -device acpi-ged,help
>>>      qemu-system-aarch64: ../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.
>>>
>>> A number of devices crash this way:
>>>
>>> * acpi-ged (aarch64 arm i386 loongarch64 x86_64)
>>> * fsl-imx6 (aarch64 arm)
>>> * fsl-imx7 (aarch64 arm)
>>> * fsl-imx8mp (aarch64)
>>> * microchip.pfsoc (riscv64)
>>> * riscv.sifive.e.soc (riscv32 riscv64)
>>> * xlnx-zynqmp (aarch64)
>> 
>> Largely speaking these are pretty useless to try to create on
>> the command line, of course...
>
> Agreed, but note that you can also query help for non-user-creatable devices 
> normally, e.g.:
>
> $ ./qemu-system-x86_64 -device port92
> qemu-system-x86_64: -device port92: Parameter 'driver' expects a pluggable 
> device type
> $ ./qemu-system-x86_64 -device port92,help
> port92 options:
>    a20[0]=<link<irq>>
>    port92[0]=<child<memory-region>>

Correct.

QOM introspection needs to create and destroy an object, and this must
effectively be a no-op.  I don't like that part of its design, but it's
what we got.

> ... so we likely should fix the crashes anyway, even if we decide to mark 
> the devices with user_creatable = false.

In fact, the devices mentioned above are all marked already.

Re: -device T,help crashes

[Markus Armbruster]

Markus Armbruster <armbru@redhat.com> writes:

> Watch this:
>
>     $ qemu-system-aarch64 -S -display none -M virt -device acpi-ged,help
>     qemu-system-aarch64: ../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.
>
> A number of devices crash this way:
>
> * acpi-ged (aarch64 arm i386 loongarch64 x86_64)
> * fsl-imx6 (aarch64 arm)
> * fsl-imx7 (aarch64 arm)
> * fsl-imx8mp (aarch64)
> * microchip.pfsoc (riscv64)
> * riscv.sifive.e.soc (riscv32 riscv64)
> * xlnx-zynqmp (aarch64)

Alistair Francis posted a fix

    Subject: [PATCH 0/7] Fix some -device T,help crashes
    Date: Thu, 12 Mar 2026 14:31:51 +1000
    Message-ID: <20260312043158.4191378-1-alistair.francis@wdc.com>

Thanks, Alistair!

> Here's another one:
>
>     $ qemu-system-sparc64 -S -display none -M virt -device sun4u-iommu,help
>     qemu-system-sparc64: ../system/physmem.c:1401: register_multipage: Assertion `num_pages' failed.
>
> Devices crashing this way:
>
> * Loongson-3A4000-mips64-cpu (mips64 mips64el)
> * dc232b-xtensa-cpu (xtensa)
> * dc233c-xtensa-cpu (xtensa)
> * de212-xtensa-cpu (xtensa)
> * de233_fpu-xtensa-cpu (xtensa)
> * dsp3400-xtensa-cpu (xtensa)
> * fsf-xtensa-cpu (xtensaeb)
> * lx106-xtensa-cpu (xtensa)
> * sample_controller-xtensa-cpu (xtensa)
> * sun4m-iommu (sparc)
> * sun4u-iommu (sparc64)
> * test_kc705_be-xtensa-cpu (xtensaeb)
> * test_mmuhifi_c3-xtensa-cpu (xtensa)

Thomas Huth posted fixes for mips and xtensa

    Subject: [PATCH] target/mips/cpu: Move initialization of memory region to realize function 
    Date: Wed, 11 Mar 2026 22:16:29 +0100
    Message-ID: <20260311211629.118608-1-thuth@redhat.com>

    Subject: [PATCH] target/xtensa/cpu: Move initialization of memory region to realize function
    Date: Wed, 11 Mar 2026 21:25:03 +0100
    Message-ID: <20260311202503.107026-1-thuth@redhat.com>

Thanks, Thomas!

We still need a fix for sparc.

> These crashes escape tests/qtest/device-introspect-test, because it
> covers only HMP "device_add T,help", not CLI "-device T,help".

Anyone wants to cook up a patch to cover -device?

Re: -device T,help crashes

[Thomas Huth]

On 12/03/2026 09.15, Markus Armbruster wrote:
> Markus Armbruster <armbru@redhat.com> writes:
...
>> These crashes escape tests/qtest/device-introspect-test, because it
>> covers only HMP "device_add T,help", not CLI "-device T,help".
> 
> Anyone wants to cook up a patch to cover -device?

Quick'n'dirty patch:

diff --git a/tests/qtest/device-introspect-test.c 
b/tests/qtest/device-introspect-test.c
--- a/tests/qtest/device-introspect-test.c
+++ b/tests/qtest/device-introspect-test.c
@@ -105,6 +105,7 @@ static void test_one_device(QTestState *qts, const char 
*type)
      QDict *resp;
      char *help, *escaped;
      GRegex *comma;
+    int ret;

      g_test_message("Testing device '%s'", type);

@@ -119,6 +120,17 @@ static void test_one_device(QTestState *qts, const char 
*type)

      help = qtest_hmp(qts, "device_add \"%s,help\"", escaped);
      g_free(help);
+
+    if (!g_str_equal(type, "nonexistent") && !g_str_equal(type, "device")) {
+        help = g_strdup_printf("%s -device \"%s,help\" > /dev/null", 
qtest_qemu_binary(NULL), escaped);
+        ret = system(help);
+        g_free(help);
+        if (ret) {
+            fprintf(stderr, "Running qemu with -device %s,help failed!\n", 
escaped);
+            abort();
+        }
+    }
+
      g_free(escaped);
  }

But I think it needs some more work - we likely don't want to run this for 
each test run since it slows down the test quite a bit. And the 
g_test_quick() switch is already used for something else here.

Anyway, found these additional issues so far:

  ./qemu-system-ppc -device raven-pcihost,help
  Segmentation fault (core dumped)
  ./qemu-system-sparc -device cgthree,help
  Segmentation fault (core dumped)

  Thomas

Re: -device T,help crashes

[Markus Armbruster]

Thomas Huth <thuth@redhat.com> writes:

> On 12/03/2026 09.15, Markus Armbruster wrote:
>> Markus Armbruster <armbru@redhat.com> writes:
> ...
>>> These crashes escape tests/qtest/device-introspect-test, because it
>>> covers only HMP "device_add T,help", not CLI "-device T,help".
>>
>> Anyone wants to cook up a patch to cover -device?
>
> Quick'n'dirty patch:
>
> diff --git a/tests/qtest/device-introspect-test.c b/tests/qtest/device-introspect-test.c
> --- a/tests/qtest/device-introspect-test.c
> +++ b/tests/qtest/device-introspect-test.c
> @@ -105,6 +105,7 @@ static void test_one_device(QTestState *qts, const char *type)
>      QDict *resp;
>      char *help, *escaped;
>      GRegex *comma;
> +    int ret;
>
>      g_test_message("Testing device '%s'", type);
>
> @@ -119,6 +120,17 @@ static void test_one_device(QTestState *qts, const char *type)
>
>      help = qtest_hmp(qts, "device_add \"%s,help\"", escaped);
>      g_free(help);
> +
> +    if (!g_str_equal(type, "nonexistent") && !g_str_equal(type, "device")) {
> +        help = g_strdup_printf("%s -device \"%s,help\" > /dev/null", qtest_qemu_binary(NULL), escaped);
> +        ret = system(help);

Not using qtest_init() or similar.  Hmm.

> +        g_free(help);
> +        if (ret) {
> +            fprintf(stderr, "Running qemu with -device %s,help failed!\n", escaped);
> +            abort();
> +        }
> +    }
> +
>      g_free(escaped);
>  }
>
> But I think it needs some more work - we likely don't want to run this for each test run since it slows down the test quite a bit. And the g_test_quick() switch is already used for something else here.

It's used to test with every machine type, not just with "none".

I think we could also use it to additionally test -device just with
"none".  Testing it with every machine type would be even slower, and I
doubt it's worthwhile.

Another idea to conserve cycles: use a unit test instead.

> Anyway, found these additional issues so far:
>
>  ./qemu-system-ppc -device raven-pcihost,help
>  Segmentation fault (core dumped)
>  ./qemu-system-sparc -device cgthree,help
>  Segmentation fault (core dumped)

One more: sparc sun-tcx

Re: -device T,help crashes

[Thomas Huth]

On 17/03/2026 08.35, Markus Armbruster wrote:
> Thomas Huth <thuth@redhat.com> writes:
> 
>> On 12/03/2026 09.15, Markus Armbruster wrote:
>>> Markus Armbruster <armbru@redhat.com> writes:
>> ...
>>>> These crashes escape tests/qtest/device-introspect-test, because it
>>>> covers only HMP "device_add T,help", not CLI "-device T,help".
>>>
>>> Anyone wants to cook up a patch to cover -device?
>>
>> Quick'n'dirty patch:
>>
>> diff --git a/tests/qtest/device-introspect-test.c b/tests/qtest/device-introspect-test.c
>> --- a/tests/qtest/device-introspect-test.c
>> +++ b/tests/qtest/device-introspect-test.c
>> @@ -105,6 +105,7 @@ static void test_one_device(QTestState *qts, const char *type)
>>       QDict *resp;
>>       char *help, *escaped;
>>       GRegex *comma;
>> +    int ret;
>>
>>       g_test_message("Testing device '%s'", type);
>>
>> @@ -119,6 +120,17 @@ static void test_one_device(QTestState *qts, const char *type)
>>
>>       help = qtest_hmp(qts, "device_add \"%s,help\"", escaped);
>>       g_free(help);
>> +
>> +    if (!g_str_equal(type, "nonexistent") && !g_str_equal(type, "device")) {
>> +        help = g_strdup_printf("%s -device \"%s,help\" > /dev/null", qtest_qemu_binary(NULL), escaped);
>> +        ret = system(help);
> 
> Not using qtest_init() or similar.  Hmm.

I mentioned it's quick-n-dirty ;-)

>> +        g_free(help);
>> +        if (ret) {
>> +            fprintf(stderr, "Running qemu with -device %s,help failed!\n", escaped);
>> +            abort();
>> +        }
>> +    }
>> +
>>       g_free(escaped);
>>   }
>>
>> But I think it needs some more work - we likely don't want to run this for each test run since it slows down the test quite a bit. And the g_test_quick() switch is already used for something else here.
> 
> It's used to test with every machine type, not just with "none".
> 
> I think we could also use it to additionally test -device just with
> "none".  Testing it with every machine type would be even slower, and I
> doubt it's worthwhile.

Agreed.

> Another idea to conserve cycles: use a unit test instead.

Unit tests don't have a way yet to determine which qemu-system-xyz binaries 
are available, do they? ... so that would need some more logic in the 
meson.build file there - not sure whether that's worth the effort, I think 
the device-introspect qtest is likely a better place?

Or maybe add it to scripts/device-crash-test ?

>> Anyway, found these additional issues so far:
>>
>>   ./qemu-system-ppc -device raven-pcihost,help
>>   Segmentation fault (core dumped)

Fix: 
https://lore.kernel.org/qemu-devel/20260317074049.436460-1-thuth@redhat.com/

>>   ./qemu-system-sparc -device cgthree,help
>>   Segmentation fault (core dumped)

Fix: 
https://lore.kernel.org/qemu-devel/20260317080623.438230-1-thuth@redhat.com/

> One more: sparc sun-tcx

That's a known issue already, so I did not mention it again:

https://lore.kernel.org/qemu-devel/afa7d52b-7087-4256-996a-b8ca7b2bfb95@redhat.com/

  Thomas

Re: -device T,help crashes

[Markus Armbruster]

Thomas Huth <thuth@redhat.com> writes:

> On 17/03/2026 08.35, Markus Armbruster wrote:
>> Thomas Huth <thuth@redhat.com> writes:
>> 
>>> On 12/03/2026 09.15, Markus Armbruster wrote:
>>>> Markus Armbruster <armbru@redhat.com> writes:
>>> ...
>>>>> These crashes escape tests/qtest/device-introspect-test, because it
>>>>> covers only HMP "device_add T,help", not CLI "-device T,help".
>>>>
>>>> Anyone wants to cook up a patch to cover -device?
>>>
>>> Quick'n'dirty patch:
>>>
>>> diff --git a/tests/qtest/device-introspect-test.c b/tests/qtest/device-introspect-test.c
>>> --- a/tests/qtest/device-introspect-test.c
>>> +++ b/tests/qtest/device-introspect-test.c
>>> @@ -105,6 +105,7 @@ static void test_one_device(QTestState *qts, const char *type)
>>>       QDict *resp;
>>>       char *help, *escaped;
>>>       GRegex *comma;
>>> +    int ret;
>>>
>>>       g_test_message("Testing device '%s'", type);
>>>
>>> @@ -119,6 +120,17 @@ static void test_one_device(QTestState *qts, const char *type)
>>>
>>>       help = qtest_hmp(qts, "device_add \"%s,help\"", escaped);
>>>       g_free(help);
>>> +
>>> +    if (!g_str_equal(type, "nonexistent") && !g_str_equal(type, "device")) {
>>> +        help = g_strdup_printf("%s -device \"%s,help\" > /dev/null", qtest_qemu_binary(NULL), escaped);
>>> +        ret = system(help);
>> 
>> Not using qtest_init() or similar.  Hmm.
>
> I mentioned it's quick-n-dirty ;-)

Fair, fair :)

>>> +        g_free(help);
>>> +        if (ret) {
>>> +            fprintf(stderr, "Running qemu with -device %s,help failed!\n", escaped);
>>> +            abort();
>>> +        }
>>> +    }
>>> +
>>>       g_free(escaped);
>>>   }
>>>
>>> But I think it needs some more work - we likely don't want to run this for each test run since it slows down the test quite a bit. And the g_test_quick() switch is already used for something else here.
>> 
>> It's used to test with every machine type, not just with "none".
>> 
>> I think we could also use it to additionally test -device just with
>> "none".  Testing it with every machine type would be even slower, and I
>> doubt it's worthwhile.
>
> Agreed.
>
>> Another idea to conserve cycles: use a unit test instead.
>
> Unit tests don't have a way yet to determine which qemu-system-xyz binaries 
> are available, do they? ... so that would need some more logic in the 
> meson.build file there - not sure whether that's worth the effort, I think 
> the device-introspect qtest is likely a better place?

A unit test isn't supposed to run qemu-system-xyz.  Instead, it mocks up
the environment and just runs "the unit".  In this case,
qdev_device_help().

This is less protection than a qtest, but it can also be a lot faster.

> Or maybe add it to scripts/device-crash-test ?

That's another option.

[...]

Re: -device T,help crashes

[Thomas Huth]

On 17/03/2026 10.27, Markus Armbruster wrote:
> Thomas Huth <thuth@redhat.com> writes:
> 
>> On 17/03/2026 08.35, Markus Armbruster wrote:
>>> Thomas Huth <thuth@redhat.com> writes:
>>>
>>>> On 12/03/2026 09.15, Markus Armbruster wrote:
>>>>> Markus Armbruster <armbru@redhat.com> writes:
>>>> ...
>>>>>> These crashes escape tests/qtest/device-introspect-test, because it
>>>>>> covers only HMP "device_add T,help", not CLI "-device T,help".
>>>>>
>>>>> Anyone wants to cook up a patch to cover -device?
...
>>> Another idea to conserve cycles: use a unit test instead.
>>
>> Unit tests don't have a way yet to determine which qemu-system-xyz binaries
>> are available, do they? ... so that would need some more logic in the
>> meson.build file there - not sure whether that's worth the effort, I think
>> the device-introspect qtest is likely a better place?
> 
> A unit test isn't supposed to run qemu-system-xyz.  Instead, it mocks up
> the environment and just runs "the unit".  In this case,
> qdev_device_help().
> 
> This is less protection than a qtest, but it can also be a lot faster.

Ok, fair, but how do you link the code for *all* the devices into that unit 
test? ... I guess that would need a lot of function stubbing?

>> Or maybe add it to scripts/device-crash-test ?
> 
> That's another option.

Maybe the best option, since it does already similar things. The only 
disadvantage is that we don't run it for all targets by default in the CI.

  Thomas

Re: -device T,help crashes

[Markus Armbruster]

Thomas Huth <thuth@redhat.com> writes:

> On 17/03/2026 10.27, Markus Armbruster wrote:
>> Thomas Huth <thuth@redhat.com> writes:
>> 
>>> On 17/03/2026 08.35, Markus Armbruster wrote:
>>>> Thomas Huth <thuth@redhat.com> writes:
>>>>
>>>>> On 12/03/2026 09.15, Markus Armbruster wrote:
>>>>>> Markus Armbruster <armbru@redhat.com> writes:
>>>>> ...
>>>>>>> These crashes escape tests/qtest/device-introspect-test, because it
>>>>>>> covers only HMP "device_add T,help", not CLI "-device T,help".
>>>>>>
>>>>>> Anyone wants to cook up a patch to cover -device?
> ...
>>>> Another idea to conserve cycles: use a unit test instead.
>>>
>>> Unit tests don't have a way yet to determine which qemu-system-xyz binaries
>>> are available, do they? ... so that would need some more logic in the
>>> meson.build file there - not sure whether that's worth the effort, I think
>>> the device-introspect qtest is likely a better place?
>> 
>> A unit test isn't supposed to run qemu-system-xyz.  Instead, it mocks up
>> the environment and just runs "the unit".  In this case,
>> qdev_device_help().
>> 
>> This is less protection than a qtest, but it can also be a lot faster.
>
> Ok, fair, but how do you link the code for *all* the devices into that unit 
> test? ... I guess that would need a lot of function stubbing?

Likely too much, i.e. you're right.

>>> Or maybe add it to scripts/device-crash-test ?
>> 
>> That's another option.
>
> Maybe the best option, since it does already similar things. The only 
> disadvantage is that we don't run it for all targets by default in the CI.

Feels quite acceptable to me.

The existing qtest should catch most offenders, and all offenders
capable of murdering guests.  Letting a -device T,help bug slip through
our testing isn't the end of the world.