Skip to content

Conversation

marijnvdwerf
Copy link
Owner

No description provided.

@marijnvdwerf
Copy link
Owner Author

IRC logs

[13:16] <marijnvdwerf> Hi. I'm working on a custom qemu arm machine, but qemu suddenly seems to stop doing anything (last  line with `-d all` says 'Stopped execution of TB chain before...'). Since the guest code itself seems to be fine, I'm a bit at a loss as to where to start debugging within qemu itself.
[13:20] <pm215> marijnvdwerf: that message generally means there was an interrupt to process, so the next thing usually would be that the interrupt gets taken (it can also mean the icount timer ran out if you're using icount)
[13:35] <marijnvdwerf> pm215: so something on the guest side that will have caused an interrupt? Since I didn't do anything with 'icount', I just set up a basic device with a CPU and some memory
[13:58] <marijnvdwerf> pm215: Turns out the code was setting a timer and trying to read qemu's system_clock_scale, which I hadn't set
[14:17] <pm215> marijnvdwerf: ah, yeah, if you don't set system_clock_scale then you'll have problems. we're planning to put in an assert() so that if you forget that in a board model it'll tell you rather than just silently misbehaving when the guest uses the timer
[14:23] <marijnvdwerf> pm215: Glad to hear that! I was considering filing an issue for that
[14:24] <pm215> yeah, I noticed a few weeks ago we had a couple of boards that had also missed setting it

marijnvdwerf pushed a commit that referenced this pull request Nov 2, 2021
To: <[email protected]>, <[email protected]>, <[email protected]>
CC: Li Zhijian <[email protected]>
Date: Sat, 31 Jul 2021 22:05:51 +0800 (5 weeks, 4 days, 17 hours ago)

multifd with unsupported protocol will cause a segment fault.
(gdb) bt
 #0  0x0000563b4a93faf8 in socket_connect (addr=0x0, errp=0x7f7f02675410) at ../util/qemu-sockets.c:1190
 #1 0x0000563b4a797a03 in qio_channel_socket_connect_sync
(ioc=0x563b4d16e8c0, addr=0x0, errp=0x7f7f02675410) at
../io/channel-socket.c:145
 #2  0x0000563b4a797abf in qio_channel_socket_connect_worker (task=0x563b4cd86c30, opaque=0x0) at ../io/channel-socket.c:168
 #3  0x0000563b4a792631 in qio_task_thread_worker (opaque=0x563b4cd86c30) at ../io/task.c:124
 #4  0x0000563b4a91da69 in qemu_thread_start (args=0x563b4c44bb80) at ../util/qemu-thread-posix.c:541
 qemu#5  0x00007f7fe9b5b3f9 in ?? ()
 qemu#6  0x0000000000000000 in ?? ()

It's enough to check migrate_multifd_is_allowed() in multifd cleanup() and
multifd setup() though there are so many other places using migrate_use_multifd().

Signed-off-by: Li Zhijian <[email protected]>
Reviewed-by: Juan Quintela <[email protected]>
Signed-off-by: Juan Quintela <[email protected]>
marijnvdwerf pushed a commit that referenced this pull request Nov 2, 2021
PCI resource reserve capability should use LE format as all other PCI
things. If we don't then seabios won't boot:

=== PCI new allocation pass #1 ===
PCI: check devices
PCI: QEMU resource reserve cap: size 10000000000000 type io
PCI: secondary bus 1 size 10000000000000 type io
PCI: secondary bus 1 size 00200000 type mem
PCI: secondary bus 1 size 00200000 type prefmem
=== PCI new allocation pass #2 ===
PCI: out of I/O address space

This became more important since we started reserving IO by default,
previously no one noticed.

Fixes: e2a6290 ("hw/pcie-root-port: Fix hotplug for PCI devices requiring IO")
Cc: [email protected]
Fixes: 226263f ("hw/pci: add QEMU-specific PCI capability to the Generic PCI Express Root Port")
Cc: [email protected]
Fixes: 6755e61 ("hw/pci: add PCI resource reserve capability to legacy PCI bridge")
Cc: [email protected]
Tested-by: Thomas Huth <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant