On Sun, 31 May 2026 09:34:52 +0800, Jia Jia <[email protected]> wrote:
Thanks for fixing the bug. The hw/ufs/lu.c change looks good to me.
One issue is in the new qtest. acpi-eject removes the UFS PCI device, but
qos-test may reuse the same QEMU instance for the next test when the command
line is unchanged. This makes the following UFS test run after the device has
already been ejected.
I can reproduce it with:
QTEST_QEMU_BINARY=./build/qemu-system-x86_64 \
build/tests/qtest/qos-test \
-p /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/ufs/ufs-tests
acpi-eject passes, then init fails.
>
> diff --git a/tests/qtest/ufs-test.c b/tests/qtest/ufs-test.c
> index f677896db0..0ae03c3433 100644
> --- a/tests/qtest/ufs-test.c
> +++ b/tests/qtest/ufs-test.c
> @@ -1426,6 +1439,9 @@ static void ufs_register_nodes(void)
> g_test_message("Skipping ufs io tests for ppc64");
> return;
> }
> + if (!strcmp(arch, "i386") || !strcmp(arch, "x86_64")) {
> + qos_add_test("acpi-eject", "ufs", ufstest_acpi_eject, NULL);
I think acpi-eject should be isolated, e.g. by registering it as a subprocess:
QOSGraphTestOptions acpi_eject_test_opts = { .subprocess = true };
qos_add_test("acpi-eject", "ufs", ufstest_acpi_eject,
&acpi_eject_test_opts);
--
Jeuk Kim <[email protected]>
