qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philmd@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>,
	Bernhard Beschow <shentey@gmail.com>
Cc: qemu-devel@nongnu.org, qemu-arm@nongnu.org,
	Paolo Bonzini <pbonzini@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	Pierrick Bouvier <pierrick.bouvier@linaro.org>,
	Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Subject: Re: [PATCH v2 0/2] KVM Support for imx8mp-evk Machine
Date: Fri, 31 Oct 2025 19:18:28 +0100	[thread overview]
Message-ID: <a7f5d348-1243-4c52-8dc1-66e2c3da40ae@linaro.org> (raw)
In-Reply-To: <CAFEAcA_sbvMEJ-oTxTYOutgUrH0iapNcJrsZd3=Ov6wNn-NE3w@mail.gmail.com>

On 31/10/25 18:12, Peter Maydell wrote:
> On Fri, 31 Oct 2025 at 16:57, Peter Maydell <peter.maydell@linaro.org> wrote:
>>
>> On Wed, 29 Oct 2025 at 14:23, Bernhard Beschow <shentey@gmail.com> wrote:
>>>
>>> This series adds KVM support to the imx8mp-evk machine, allowing it to run
>>> guests with KVM acceleration. Inspiration was taken from the virt machine. This
>>> required a device tree quirk for the guest clock to be kept in sync with the
>>> host. Without this quirk the guest's clock would advance with factor <host
>>> system counter> / 8Mhz.
>>>
>>> Testing done:
>>> * Run `qemu-system-aarch64 -M imx8mp-evk -accel kvm -smp 4` under
>>>    `qemu-system-aarch64 -M virt,secure=on,virtualization=on,gic-version=4 \
>>>    -cpu cortex-a72 -smp 4 -accel tcg` and `qemu-system-aarch64 -M imx8mp-evk \
>>>    -accel tcg -smp 4". Observe that the `date` command reflects the host's date.
>>>
>>> v2:
>>> * Mention various tradeoffs in the board documentation (Peter)
>>> * Accommodate for single-binary (Peter, Pierrick) by having CPU defaults
>>>
>>> Bernhard Beschow (2):
>>>    hw/arm/imx8mp-evk: Add KVM support
>>>    hw/arm/imx8mp-evk: Fix guest time in KVM mode
>>
>> Thanks, I've applied this to target-arm.next.
> 
> ...I've had to un-queue it, as it breaks "make check":
> 
> test:         qemu:qtest+qtest-aarch64 / qtest-aarch64/device-introspect-test
> start time:   17:06:52
> duration:     3.70s
> result:       killed by signal 6 SIGABRT
> command:      MALLOC_PERTURB_=155
> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
> PYTHON=/data_nvme1n1/linaro/qemu-from-laptop/qemu/build/arm-clang/pyvenv/bin/python3
> G_TEST_DBUS_DAEMON=/data_nvme1n1/linaro/qemu-from-laptop/qemu/tests/dbus-vmstate-daemon.sh
> RUST_BACKTRACE=1
> MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
> QTEST_QEMU_BINARY=./qemu-system-aarch64
> QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon
> ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1
> QTEST_QEMU_IMG=./qemu-img MESON_TEST_ITERATION=1
> /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/arm-clang/tests/qtest/device-introspect-test
> --tap -k
> ----------------------------------- stdout -----------------------------------
> [...]
> # Testing device 'fsl-imx8mp'
> ----------------------------------- stderr -----------------------------------
> unknown type '(null)'
> Broken pipe
> ../../tests/qtest/libqtest.c:199: kill_qemu() tried to terminate QEMU
> process but encountered exit status 1 (expected 0)
> 
> 
> I think the problem is that you're trying to use ms->cpu_type
> in the fsl_imx8mp_init() function. This doesn't work in the
> device-introspect-test setup, because it is just instantiating
> each device for test, not running a full machine.
> 
> I think the way we usually avoid this is that if an SoC
> device object needs to know what CPU type to instantiate
> it has a QOM property, and the board model tells it.
> (Annoyingly this then means the CPU instantiation has to
> move into the realize method where the property value is known.)

Correct, this is the same issue I tried to address with the Raspi
machines and I noted your comments:
https://lore.kernel.org/qemu-devel/CAFEAcA961WKB4fxwAS0WHXXKwYEO7TnmovD4z-BPGehr6sxBQw@mail.gmail.com/

> 
> Philippe may know if there's a nicer way to deal with this.
> (Would it be too ugly to just handle ms->cpu_type == NULL
> as "assume default"?)

I will think about it, but unfortunately I am not sure I'll have time
before the freeze...

This might help (untested) -- although going backward w.r.t. single
binary but not important for the 10.2 release --:

---
diff --git a/hw/arm/meson.build b/hw/arm/meson.build
index 61c66ee2d0b..151ed020d1a 100644
--- a/hw/arm/meson.build
+++ b/hw/arm/meson.build
@@ -62,4 +62,4 @@ arm_common_ss.add(when: 'CONFIG_ARMSSE', if_true: 
files('armsse.c'))
  arm_common_ss.add(when: 'CONFIG_FSL_IMX7', if_true: 
files('fsl-imx7.c', 'mcimx7d-sabre.c'))
-arm_common_ss.add(when: 'CONFIG_FSL_IMX8MP', if_true: 
files('fsl-imx8mp.c'))
-arm_common_ss.add(when: 'CONFIG_FSL_IMX8MP_EVK', if_true: 
files('imx8mp-evk.c'))
+arm_ss.add(when: 'CONFIG_FSL_IMX8MP', if_true: files('fsl-imx8mp.c'))
+arm_ss.add(when: 'CONFIG_FSL_IMX8MP_EVK', if_true: files('imx8mp-evk.c'))
  arm_common_ss.add(when: 'CONFIG_ARM_SMMUV3', if_true: files('smmuv3.c'))
---


  reply	other threads:[~2025-10-31 18:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-29 14:23 [PATCH v2 0/2] KVM Support for imx8mp-evk Machine Bernhard Beschow
2025-10-29 14:23 ` [PATCH v2 1/2] hw/arm/imx8mp-evk: Add KVM support Bernhard Beschow
2025-10-29 14:23 ` [PATCH v2 2/2] hw/arm/imx8mp-evk: Fix guest time in KVM mode Bernhard Beschow
2025-10-31 14:03   ` Philippe Mathieu-Daudé
2025-10-31 11:16 ` [PATCH v2 0/2] KVM Support for imx8mp-evk Machine Bernhard Beschow
2025-10-31 16:57 ` Peter Maydell
2025-10-31 17:12   ` Peter Maydell
2025-10-31 18:18     ` Philippe Mathieu-Daudé [this message]
2025-10-31 18:30       ` Peter Maydell
2025-11-01 12:09         ` Bernhard Beschow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a7f5d348-1243-4c52-8dc1-66e2c3da40ae@linaro.org \
    --to=philmd@linaro.org \
    --cc=manos.pitsidianakis@linaro.org \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=pierrick.bouvier@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=shentey@gmail.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).