Tags give the ability to mark specific points in history as being important
-
virtiofsd-syncfs-v4
6c34fe6c · ·virtiofsd: Add support for FUSE_SYNCFS request FUSE_SYNCFS allows the client to flush the host page cache. v4: - based on upstream linux FUSE_SYNCFS - added support for the '-o announce_submounts' case, i.e. client sends a FUSE_SYNCFS request for each submount (identified by its root inode) - adapted the case without '-o announce_submounts' so that syncfs() is no longer called with lo->mutex held v3: - track submounts and do per-submount syncfs() (Vivek) - based on new version of FUSE_SYNCFS (still not upstream) https://listman.redhat.com/archives/virtio-fs/2021-May/msg00025.html v2: - based on new version of FUSE_SYNCFS https://listman.redhat.com/archives/virtio-fs/2021-April/msg00166.html - propagate syncfs() errors to client (Vivek) -
fix-drain-call-rcu-v4
c823b31f · ·accel/tcg: Fix monitor deadlock Commit 7bed89958bfb ("device_core: use drain_call_rcu in in qmp_device_add") introduced a regression in QEMU 6.0 : passing device_add without argument hangs the monitor. This was reported against qemu-system-mips64 with TGC, but I could consistently reproduce it with other targets (x86 and ppc64). See https://gitlab.com/qemu-project/qemu/-/issues/650 for details. The problem is that an emulated busy-looping vCPU can stay forever in its RCU read-side critical section and prevent drain_call_rcu() to return. This series fixes the issue by letting RCU kick vCPU threads out of the read-side critical section when drain_call_rcu() is in progress. This is achieved through notifiers, as suggested by Paolo Bonzini. I've pushed this series to: https://gitlab.com/gkurz/qemu/-/commits/fix-drain-call-rcu v4: - use rr_kick_next_cpu() instead of async_run_on_cpu(first_cpu) v3: - new separate implementations of force RCU notifiers for MTTCG and RR v2: - moved notifier list to RCU reader data - separate API for notifier registration - CPUState passed as an opaque pointer -
fix-drain-call-rcu-v3
92705f67 · ·accel/tcg: Fix monitor deadlock Commit 7bed89958bfb ("device_core: use drain_call_rcu in in qmp_device_add") introduced a regression in QEMU 6.0 : passing device_add without argument hangs the monitor. This was reported against qemu-system-mips64 with TGC, but I could consistently reproduce it with other targets (x86 and ppc64). See https://gitlab.com/qemu-project/qemu/-/issues/650 for details. The problem is that an emulated busy-looping vCPU can stay forever in its RCU read-side critical section and prevent drain_call_rcu() to return. This series fixes the issue by letting RCU kick vCPU threads out of the read-side critical section when drain_call_rcu() is in progress. This is achieved through notifiers, as suggested by Paolo Bonzini. I've pushed this series to: https://gitlab.com/gkurz/qemu/-/commits/fix-drain-call-rcu v3: - new separate implementations of force RCU notifiers for MTTCG and RR v2: - moved notifier list to RCU reader data - separate API for notifier registration - CPUState passed as an opaque pointer -
pull-9p-20211027
7e985780 · ·9pfs: performance fix and cleanup * First patch fixes suboptimal I/O performance on guest due to previously incorrect block size being transmitted to 9p client. * Subsequent patches are cleanup ones intended to reduce code complexity.
-
fix-drain-call-rcu-v2
3dfc1d7f · ·accel/tcg: Fix monitor deadlock Commit 7bed89958bfb ("device_core: use drain_call_rcu in in qmp_device_add") introduced a regression in QEMU 6.0 : passing device_add without argument hangs the monitor. This was reported against qemu-system-mips64 with TGC, but I could consistently reproduce it with other targets (x86 and ppc64). See https://gitlab.com/qemu-project/qemu/-/issues/650 for details. The problem is that an emulated busy-looping vCPU can stay forever in its RCU read-side critical section and prevent drain_call_rcu() to return. This series fixes the issue by letting RCU kick vCPUs out of the read-side critical section when drain_call_rcu() is in progress. This is achieved through notifiers, as suggested by Paolo Bonzini. v2: - moved notifier list to RCU reader data - separate API for notifier registration - CPUState passed as an opaque pointer -
fix-drain-call-rcu-v1
d56ecb94 · ·accel/tcg: Fix monitor deadlock Commit 7bed89958bfb ("device_core: use drain_call_rcu in in qmp_device_add") introduced a regression in QEMU 6.0 : passing device_add without argument hangs the monitor. This was reported against qemu-system-mips64 with TGC, but I could consistently reproduce it with other targets (x86 and ppc64). See https://gitlab.com/qemu-project/qemu/-/issues/650 for details. The problem is that an emulated busy-looping vCPU can stay forever in its RCU read-side critical section and prevent drain_call_rcu() to return. This series fixes the issue by letting RCU kick vCPUs out of the read-side critical section when drain_call_rcu() is in progress. This is achieved through notifiers, as suggested by Paolo Bonzini. -
pull-9p-20210902
f83df009 · ·9pfs: misc patches * Fix an occasional crash when handling 'Twalk' requests. * Two code cleanup patches.