From: "Philippe Mathieu-Daudé" <philmd@linaro.org>
To: "Richard Purdie" <richard.purdie@linuxfoundation.org>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
"David Hildenbrand" <david@redhat.com>
Cc: qemu-devel@nongnu.org, Aurelien Jarno <aurelien@aurel32.net>,
Jiaxun Yang <jiaxun.yang@flygoat.com>,
Aleksandar Rikalo <aleksandar.rikalo@syrmia.com>,
Richard Henderson <richard.henderson@linaro.org>
Subject: Re: mips system emulation failure with virtio
Date: Wed, 6 Sep 2023 18:06:30 +0200 [thread overview]
Message-ID: <6c956b90-5a13-db96-9c02-9834a512fe6f@linaro.org> (raw)
In-Reply-To: <67d4c8dc-24d7-afa3-27b1-d6e756a597b9@linaro.org>
On 6/9/23 17:50, Philippe Mathieu-Daudé wrote:
> +rth/pm215/dhildenb
>
> On 5/9/23 16:50, Richard Purdie wrote:
>> On Tue, 2023-09-05 at 14:59 +0100, Alex Bennée wrote:
>>> Richard Purdie <richard.purdie@linuxfoundation.org> writes:
>>>
>>>> With qemu 8.1.0 we see boot hangs fox x86-64 targets.
>>>>
>>>> These are fixed by 0d58c660689f6da1e3feff8a997014003d928b3b (softmmu:
>>>> Use async_run_on_cpu in tcg_commit) but if I add that commit, mips and
>>>> mips64 break, hanging at boot unable to find a rootfs.
>>>
>>> (Widen CC list)
>>>
>>>>
>>>> We use virtio for network and disk and both of those change in the
>>>> bootlog from messages like:
>>>>
>>>> [ 1.726118] virtio-pci 0000:00:13.0: enabling device (0000 -> 0003)
>>>> [ 1.728864] virtio-pci 0000:00:14.0: enabling device (0000 -> 0003)
>>>> [ 1.729948] virtio-pci 0000:00:15.0: enabling device (0000 -> 0003)
>>>> ...
>>>> [ 2.162148] virtio_blk virtio2: 1/0/0 default/read/poll queues
>>>> [ 2.168311] virtio_blk virtio2: [vda] 1184242 512-byte logical
>>>>
>>>> to:
>>>>
>>>> [ 1.777051] virtio-pci 0000:00:13.0: enabling device (0000 -> 0003)
>>>> [ 1.779822] virtio-pci 0000:00:14.0: enabling device (0000 -> 0003)
>>>> [ 1.780926] virtio-pci 0000:00:15.0: enabling device (0000 -> 0003)
>>>> ...
>>>> [ 1.894852] virtio_rng: probe of virtio1 failed with error -28
>>>> ...
>>>> [ 2.063553] virtio_blk virtio2: 1/0/0 default/read/poll queues
>>>> [ 2.064260] virtio_blk: probe of virtio2 failed with error -28
>>>> [ 2.069080] virtio_net: probe of virtio0 failed with error -28
>>>>
>>>>
>>>> i.e. the virtio drivers no longer work.
>>>
>>> Interesting, as you say this seems to be VirtIO specific as the baseline
>>> tests (using IDE) work fine:
>>>
>>> ➜ ./tests/venv/bin/avocado run
>>> ./tests/avocado/tuxrun_baselines.py:test_mips64
>>> JOB ID : 71f3e3b7080164b78ef1c8c1bb6bc880932d8c9b
>>> JOB LOG :
>>> /home/alex/avocado/job-results/job-2023-09-05T15.01-71f3e3b/job.log
>>> (1/2)
>>> ./tests/avocado/tuxrun_baselines.py:TuxRunBaselineTest.test_mips64:
>>> PASS (12.19 s)
>>> (2/2)
>>> ./tests/avocado/tuxrun_baselines.py:TuxRunBaselineTest.test_mips64el:
>>> PASS (11.78 s)
>>> RESULTS : PASS 2 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 |
>>> INTERRUPT 0 | CANCEL 0
>>> JOB TIME : 24.79 s
>>>
>>>> I tested with current qemu master
>>>> (17780edd81d27fcfdb7a802efc870a99788bd2fc) and mips is still broken
>>>> there.
>>>>
>>>> Is this issue known about?
>>>
>>> Could you raise a bug at:
>>>
>>> https://gitlab.com/qemu-project/qemu/-/issues
>>
>> Done, https://gitlab.com/qemu-project/qemu/-/issues/1866
>>
>>> I'm curious why MIPS VirtIO is affected but nothing else is...
>>
>> Me too, it seems there is a real code issue somewhere in this...
>
> This seems to fix the issue for me, but I'm not really sure what
> I'm doing after various hours debugging, so sharing here before
> I take some rest:
>
> -- >8 --
> diff --git a/softmmu/physmem.c b/softmmu/physmem.c
> index 18277ddd67..ec31ebcb56 100644
> --- a/softmmu/physmem.c
> +++ b/softmmu/physmem.c
> @@ -2517,7 +2517,7 @@ static void tcg_commit(MemoryListener *listener)
> * That said, the listener is also called during realize, before
> * all of the tcg machinery for run-on is initialized: thus
> halt_cond.
> */
> - if (cpu->halt_cond) {
> + if (cpu->halt_cond && !qemu_cpu_is_self(cpu)) {
> async_run_on_cpu(cpu, tcg_commit_cpu,
> RUN_ON_CPU_HOST_PTR(cpuas));
> } else {
> tcg_commit_cpu(cpu, RUN_ON_CPU_HOST_PTR(cpuas));
> ---
>
> That said, the same logic moved generically to async_run_on_cpu()
> also works ...:
>
> -- >8 --
> diff --git a/cpus-common.c b/cpus-common.c
> index 45c745ecf6..b0539c4fb8 100644
> --- a/cpus-common.c
> +++ b/cpus-common.c
> @@ -167,6 +167,9 @@ void do_run_on_cpu(CPUState *cpu, run_on_cpu_func
> func, run_on_cpu_data data,
>
> void async_run_on_cpu(CPUState *cpu, run_on_cpu_func func,
> run_on_cpu_data data)
> {
> + if (qemu_cpu_is_self(cpu)) {
> + return func(cpu, data);
> + }
> struct qemu_work_item *wi;
>
> wi = g_new0(struct qemu_work_item, 1);
> ---
Ah, this is what commit c978b31687 removed:
commit c978b3168727d3a76ffcb18462ea972f50b53634
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Wed Aug 31 18:03:39 2016 +0200
cpus-common: always defer async_run_on_cpu work items
async_run_on_cpu is only called from the I/O thread, not from
CPU threads, so it doesn't make any difference. It will make
a difference however for async_safe_run_on_cpu.
So adding:
-- >8 --
diff --git a/cpus-common.c b/cpus-common.c
index 45c745ecf6..8554e3f7a1 100644
--- a/cpus-common.c
+++ b/cpus-common.c
@@ -169,6 +169,8 @@ void async_run_on_cpu(CPUState *cpu, run_on_cpu_func
func, run_on_cpu_data data)
{
struct qemu_work_item *wi;
+ g_assert(!qemu_cpu_is_self(cpu));
+
wi = g_new0(struct qemu_work_item, 1);
wi->func = func;
wi->data = data;
---
We get:
* thread #4, stop reason = signal SIGABRT
* frame #0: 0x00000001887d8764 libsystem_kernel.dylib`__pthread_kill + 8
frame #1: 0x000000018880fc28 libsystem_pthread.dylib`pthread_kill + 288
frame #2: 0x000000018871dae8 libsystem_c.dylib`abort + 180
frame #3: 0x0000000101efdddc
libglib-2.0.0.dylib`g_assertion_message + 464
frame #4: 0x0000000101efde50
libglib-2.0.0.dylib`g_assertion_message_expr + 116
frame #5: 0x000000010000f6a8
qemu-system-mips`async_run_on_cpu(cpu=0x0000000104815a00,
func=(qemu-system-mips`tcg_commit_cpu at physmem.c:2490), data=(host_int
= 61900768, host_ulong = 105553178167264, host_ptr = 0x0000600003b087e0,
target_ptr = 105553178167264)) at cpus-common.c:172:5
frame #6: 0x00000001004d469c
qemu-system-mips`tcg_commit(listener=0x0000600003b087f8) at physmem.c:2521:9
frame #7: 0x00000001004c4b70
qemu-system-mips`memory_region_transaction_commit at memory.c:1126:13
frame #8: 0x000000010020f620
qemu-system-mips`gt64120_isd_mapping(s=0x0000000104875c00) at
gt64120.c:318:5
frame #9: 0x000000010020dbe4
qemu-system-mips`gt64120_writel(opaque=0x0000000104875c00, addr=104,
val=223, size=4) at gt64120.c:502:9
frame #10: 0x00000001004c638c
qemu-system-mips`memory_region_write_accessor(mr=0x0000000104877600,
addr=104, value=0x000000016ff9e2f0, size=4, shift=0, mask=4294967295,
attrs=MemTxAttrs @ 0x000000016ff9e21c) at memory.c:493:5
frame #11: 0x00000001004c6160
qemu-system-mips`access_with_adjusted_size(addr=104,
value=0x000000016ff9e2f0, size=4, access_size_min=4, access_size_max=4,
access_fn=(qemu-system-mips`memory_region_write_accessor at
memory.c:483), mr=0x0000000104877600, attrs=MemTxAttrs @
0x000000016ff9e2a8) at memory.c:564:18
frame #12: 0x00000001004c5cd0
qemu-system-mips`memory_region_dispatch_write(mr=0x0000000104877600,
addr=104, data=3741319168, op=MO_32, attrs=MemTxAttrs @
0x000000016ff9e2e8) at memory.c:1533:16
frame #13: 0x00000001004decc0
qemu-system-mips`flatview_write_continue(fv=0x00006000017151c0,
addr=335544424, attrs=MemTxAttrs @ 0x000000016ff9e384,
ptr=0x000000016ff9e450, len=4, addr1=104, l=4, mr=0x0000000104877600) at
physmem.c:2677:23
frame #14: 0x00000001004db090
qemu-system-mips`flatview_write(fv=0x00006000017151c0, addr=335544424,
attrs=MemTxAttrs @ 0x000000016ff9e3e0, buf=0x000000016ff9e450, len=4) at
physmem.c:2719:12
frame #15: 0x00000001004e2f54
qemu-system-mips`subpage_write(opaque=0x0000000104907400, addr=104,
value=3741319168, len=4, attrs=MemTxAttrs @ 0x000000016ff9e44c) at
physmem.c:2328:12
frame #16: 0x00000001004c64dc
qemu-system-mips`memory_region_write_with_attrs_accessor(mr=0x0000000104907400,
addr=104, value=0x000000016ff9e5a0, size=4, shift=0, mask=4294967295,
attrs=MemTxAttrs @ 0x000000016ff9e4cc) at memory.c:514:12
frame #17: 0x00000001004c6160
qemu-system-mips`access_with_adjusted_size(addr=104,
value=0x000000016ff9e5a0, size=4, access_size_min=1, access_size_max=8,
access_fn=(qemu-system-mips`memory_region_write_with_attrs_accessor at
memory.c:504), mr=0x0000000104907400, attrs=MemTxAttrs @
0x000000016ff9e558) at memory.c:564:18
frame #18: 0x00000001004c5d14
qemu-system-mips`memory_region_dispatch_write(mr=0x0000000104907400,
addr=104, data=3741319168, op=MO_32, attrs=MemTxAttrs @
0x000000016ff9e598) at memory.c:1540:13
frame #19: 0x000000010054f5c8
qemu-system-mips`io_writex(env=0x0000000104818260,
full=0x0000000104828000, mmu_idx=3, val=223, addr=3019898984,
retaddr=10737419088, op=MO_32) at cputlb.c:1449:13
frame #20: 0x000000010054f9a4
qemu-system-mips`do_st_mmio_leN(env=0x0000000104818260,
full=0x0000000104828000, val_le=223, addr=3019898984, size=4, mmu_idx=3,
ra=10737419088) at cputlb.c:2756:13
frame #21: 0x00000001005500bc
qemu-system-mips`do_st_4(env=0x0000000104818260, p=0x000000016ff9e760,
val=223, mmu_idx=3, memop=226, ra=10737419088) at cputlb.c:2922:9
frame #22: 0x000000010053dff0
qemu-system-mips`do_st4_mmu(env=0x0000000104818260, addr=3019898984,
val=223, oi=3619, ra=10737419088) at cputlb.c:3007:9
frame #23: 0x000000010053df44
qemu-system-mips`helper_stl_mmu(env=0x0000000104818260, addr=3019898984,
val=223, oi=3619, retaddr=10737419088) at cputlb.c:3023:5
frame #24: 0x0000000280000624
frame #25: 0x0000000100522e70
qemu-system-mips`cpu_tb_exec(cpu=0x0000000104815a00,
itb=0x0000000118000200, tb_exit=0x000000016ff9ee24) at cpu-exec.c:457:11
frame #26: 0x0000000100525714
qemu-system-mips`cpu_loop_exec_tb(cpu=0x0000000104815a00,
tb=0x0000000118000200, pc=3217032576, last_tb=0x000000016ff9ee28,
tb_exit=0x000000016ff9ee24) at cpu-exec.c:919:10
frame #27: 0x0000000100524d3c
qemu-system-mips`cpu_exec_loop(cpu=0x0000000104815a00,
sc=0x000000016ff9eea0) at cpu-exec.c:1040:13
frame #28: 0x000000010052366c
qemu-system-mips`cpu_exec_setjmp(cpu=0x0000000104815a00,
sc=0x000000016ff9eea0) at cpu-exec.c:1057:12
frame #29: 0x0000000100523340
qemu-system-mips`cpu_exec(cpu=0x0000000104815a00) at cpu-exec.c:1083:11
frame #30: 0x00000001005569bc
qemu-system-mips`tcg_cpus_exec(cpu=0x0000000104815a00) at
tcg-accel-ops.c:75:11
frame #31: 0x00000001005575c4
qemu-system-mips`mttcg_cpu_thread_fn(arg=0x0000000104815a00) at
tcg-accel-ops-mttcg.c:95:17
frame #32: 0x00000001007d86c8
qemu-system-mips`qemu_thread_start(args=0x000060000022e400) at
qemu-thread-posix.c:541:9
frame #33: 0x000000018880ffa8
libsystem_pthread.dylib`_pthread_start + 148
(in case that helps catching other similar issues).
next prev parent reply other threads:[~2023-09-06 16:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-05 13:19 mips system emulation failure with virtio Richard Purdie
2023-09-05 13:59 ` Alex Bennée
2023-09-05 14:50 ` Richard Purdie
2023-09-05 15:12 ` Philippe Mathieu-Daudé
2023-09-05 15:53 ` Richard Purdie
2023-09-05 16:46 ` Philippe Mathieu-Daudé
2023-09-05 16:50 ` Richard Purdie
2023-09-06 15:50 ` Philippe Mathieu-Daudé
2023-09-06 16:06 ` Philippe Mathieu-Daudé [this message]
2023-09-06 16:46 ` Richard Purdie
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=6c956b90-5a13-db96-9c02-9834a512fe6f@linaro.org \
--to=philmd@linaro.org \
--cc=aleksandar.rikalo@syrmia.com \
--cc=alex.bennee@linaro.org \
--cc=aurelien@aurel32.net \
--cc=david@redhat.com \
--cc=jiaxun.yang@flygoat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=richard.purdie@linuxfoundation.org \
/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).