nbd/server: Mark negotiation functions as coroutine_fn
nbd_negotiate() is already marked coroutine_fn. And given the fix in
the previous patch to have nbd_negotiate_handle_starttls not create
and wait on a g_main_loop (as that would violate coroutine
constraints), it is worth marking the rest of the related static
functions reachable only during option negotiation as also being
coroutine_fn.
Suggested-by: Vladimir Sementsov-Ogievskiy <email address hidden>
Signed-off-by: Eric Blake <email address hidden>
Message-ID: <email address hidden>
Reviewed-by: Vladimir Sementsov-Ogievskiy <email address hidden>
[eblake: drop one spurious coroutine_fn marking]
Signed-off-by: Eric Blake <email address hidden>
(cherry picked from commit 4fa333e08dd96395a99ea8dd9e4c73a29dd23344)
Signed-off-by: Michael Tokarev <email address hidden>
nbd/server: do not poll within a coroutine context
Coroutines are not supposed to block. Instead, they should yield.
The client performs TLS upgrade outside of an AIOContext, during
synchronous handshake; this still requires g_main_loop. But the
server responds to TLS upgrade inside a coroutine, so a nested
g_main_loop is wrong. Since the two callbacks no longer share more
than the setting of data.complete and data.error, it's just as easy to
use static helpers instead of trying to share a common code path. It
is also possible to add assertions that no other code is interfering
with the eventual path to qio reaching the callback, whether or not it
required a yield or main loop.
Fixes: f95910f ("nbd: implement TLS support in the protocol negotiation")
Signed-off-by: Zhu Yangyang <email address hidden>
[eblake: move callbacks to their use point, add assertions]
Signed-off-by: Eric Blake <email address hidden>
Message-ID: <email address hidden>
Reviewed-by: Vladimir Sementsov-Ogievskiy <email address hidden>
(cherry picked from commit ae6d91a7e9b77abb029ed3fa9fad461422286942)
Signed-off-by: Michael Tokarev <email address hidden>
6fee9ef...
by
Michael Tokarev <email address hidden>
This setsockopt accepts zero-lengh optlen (current qemu implementation
does not allow this). Also, there's no need to make a copy of the key,
it is enough to use lock_user() (which accepts zero length already).
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2197
Fixes: f31dddd2fc "linux-user: Add support for setsockopt() option SOL_ALG"
Signed-off-by: Michael Tokarev <email address hidden>
Message-Id: <email address hidden>
Signed-off-by: Richard Henderson <email address hidden>
(cherry picked from commit 04f6fb897a5aeb3e356a7b889869c9962f9c16c7)
Signed-off-by: Michael Tokarev <email address hidden>
bdrv_activate_all() should not be called from the coroutine context, move
it to the QEMU thread colo_process_incoming_thread() with the bql_lock
protected.
The backtrace is as follows:
#4 0x0000561af7948362 in bdrv_graph_rdlock_main_loop () at ../block/graph-lock.c:260
#5 0x0000561af7907a68 in graph_lockable_auto_lock_mainloop (x=0x7fd29810be7b) at /patch/to/qemu/include/block/graph-lock.h:259
#6 0x0000561af79167d1 in bdrv_activate_all (errp=0x7fd29810bed0) at ../block.c:6906
#7 0x0000561af762b4af in colo_incoming_co () at ../migration/colo.c:935
#8 0x0000561af7607e57 in process_incoming_migration_co (opaque=0x0) at ../migration/migration.c:793
#9 0x0000561af7adbeeb in coroutine_trampoline (i0=-106876144, i1=22042) at ../util/coroutine-ucontext.c:175
#10 0x00007fd2a5cf21c0 in () at /lib64/libc.so.6
Cc: <email address hidden>
Cc: Fabiano Rosas <email address hidden>
Closes: https://gitlab.com/qemu-project/qemu/-/issues/2277
Fixes: 2b3912f135 ("block: Mark bdrv_first_blk() and bdrv_is_root_node() GRAPH_RDLOCK")
Signed-off-by: Li Zhijian <email address hidden>
Reviewed-by: Zhang Chen <email address hidden>
Tested-by: Zhang Chen <email address hidden>
Reviewed-by: Fabiano Rosas <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Peter Xu <email address hidden>
(cherry picked from commit 2cc637f1ea08d2a1b19fc5b1a30bc609f948de93)
Signed-off-by: Michael Tokarev <email address hidden>
(Mjt: fixup bql_lock() => qemu_mutex_lock_iothread() for v8.2.0-444-g195801d700c0
"system/cpus: rename qemu_mutex_lock_iothread() to bql_lock()")
cbae108...
by
Daniel Henrique Barboza <email address hidden>
target/riscv/kvm: change timer regs size to u64
KVM_REG_RISCV_TIMER regs are always u64 according to the KVM API, but at
this moment we'll return u32 regs if we're running a RISCV32 target.
Use the kvm_riscv_reg_id_u64() helper in RISCV_TIMER_REG() to fix it.
Reported-by: Andrew Jones <email address hidden>
Signed-off-by: Daniel Henrique Barboza <email address hidden>
Reviewed-by: Andrew Jones <email address hidden>
Message-ID: <email address hidden>
Signed-off-by: Alistair Francis <email address hidden>
(cherry picked from commit 10f86d1b845087d14b58d65dd2a6e3411d1b6529)
Signed-off-by: Michael Tokarev <email address hidden>
125b95d...
by
Daniel Henrique Barboza <email address hidden>
target/riscv/kvm: change KVM_REG_RISCV_FP_D to u64
KVM_REG_RISCV_FP_D regs are always u64 size. Using kvm_riscv_reg_id() in
RISCV_FP_D_REG() ends up encoding the wrong size if we're running with
TARGET_RISCV32.
Create a new helper that returns a KVM ID with u64 size and use it with
RISCV_FP_D_REG().
Reported-by: Andrew Jones <email address hidden>
Signed-off-by: Daniel Henrique Barboza <email address hidden>
Reviewed-by: Andrew Jones <email address hidden>
Message-ID: <email address hidden>
Signed-off-by: Alistair Francis <email address hidden>
(cherry picked from commit 450bd6618fda3d2e2ab02b2fce1c79efd5b66084)
Signed-off-by: Michael Tokarev <email address hidden>
bbdcc89...
by
Daniel Henrique Barboza <email address hidden>
target/riscv/kvm: change KVM_REG_RISCV_FP_F to u32
KVM_REG_RISCV_FP_F regs have u32 size according to the API, but by using
kvm_riscv_reg_id() in RISCV_FP_F_REG() we're returning u64 sizes when
running with TARGET_RISCV64. The most likely reason why no one noticed
this is because we're not implementing kvm_cpu_synchronize_state() in
RISC-V yet.
Create a new helper that returns a KVM ID with u32 size and use it in
RISCV_FP_F_REG().
Reported-by: Andrew Jones <email address hidden>
Signed-off-by: Daniel Henrique Barboza <email address hidden>
Reviewed-by: Andrew Jones <email address hidden>
Message-ID: <email address hidden>
Signed-off-by: Alistair Francis <email address hidden>
(cherry picked from commit 49c211ffca00fdf7c0c29072c224e88527a14838)
Signed-off-by: Michael Tokarev <email address hidden>
8216663...
by
Michael Tokarev <email address hidden>
Update version for 8.2.3 release
Signed-off-by: Michael Tokarev <email address hidden>
51da750...
by
Harsh Prateek Bora <email address hidden>
ppc/spapr: Initialize max_cpus limit to SPAPR_IRQ_NR_IPIS.
Initialize the machine specific max_cpus limit as per the maximum range
of CPU IPIs available. Keeping between 4096 to 8192 will throw IRQ not
free error due to XIVE/XICS limitation and keeping beyond 8192 will hit
assert in tcg_region_init or spapr_xive_claim_irq.
Logs:
Without patch fix:
[root@host build]# qemu-system-ppc64 -accel tcg -smp 10,maxcpus=4097
qemu-system-ppc64: IRQ 4096 is not free
[root@host build]#
With patch fix:
[root@host build]# qemu-system-ppc64 -accel tcg -smp 10,maxcpus=4097
qemu-system-ppc64: Invalid SMP CPUs 4097. The max CPUs supported by
machine 'pseries-8.2' is 4096
[root@host build]#
Reported-by: Kowshik Jois <email address hidden>
Tested-by: Kowshik Jois <email address hidden>
Reviewed-by: Cédric Le Goater <email address hidden>
Signed-off-by: Harsh Prateek Bora <email address hidden>
Signed-off-by: Nicholas Piggin <email address hidden>
(cherry picked from commit c4f91d7b7be76c47015521ab0109c6e998a369b0)
Signed-off-by: Michael Tokarev <email address hidden>
c513ee1...
by
Harsh Prateek Bora <email address hidden>
ppc/spapr: Introduce SPAPR_IRQ_NR_IPIS to refer IRQ range for CPU IPIs.
spapr_irq_init currently uses existing macro SPAPR_XIRQ_BASE to refer to
the range of CPU IPIs during initialization of nr-irqs property.
It is more appropriate to have its own define which can be further
reused as appropriate for correct interpretation.
Suggested-by: Cedric Le Goater <email address hidden>
Reviewed-by: Cédric Le Goater <email address hidden>
Tested-by: Kowshik Jois <email address hidden>
Signed-off-by: Harsh Prateek Bora <email address hidden>
Signed-off-by: Nicholas Piggin <email address hidden>
(cherry picked from commit 2df5c1f5b014126595a26c6797089d284a3b211c)
Signed-off-by: Michael Tokarev <email address hidden>
