Re: [PATCH 1/6] system/cpus: rename qemu_mutex_lock_iothread() to qemu_bql_lock()
On Fri, Dec 01, 2023 at 10:42:43AM +0530, Harsh Prateek Bora wrote:
> On 11/30/23 02:56, Stefan Hajnoczi wrote:
> > diff --git a/hw/remote/mpqemu-link.c b/hw/remote/mpqemu-link.c
> > index 9bd98e8219..ffb2c25145 100644
> > --- a/hw/remote/mpqemu-link.c
> > +++ b/hw/remote/mpqemu-link.c
> > @@ -33,7 +33,7 @@
> >*/
> > bool mpqemu_msg_send(MPQemuMsg *msg, QIOChannel *ioc, Error **errp)
> > {
> > -bool iolock = qemu_mutex_iothread_locked();
> > +bool iolock = qemu_bql_locked();
>
> Should var name (one more below) be updated to reflect this update ?
Yes. I'll grep for that tree-wide because there might be other
instances.
Stefan
signature.asc
Description: PGP signature
Re: [PATCH 1/6] system/cpus: rename qemu_mutex_lock_iothread() to qemu_bql_lock()
On Wed, 2023-11-29 at 16:26 -0500, Stefan Hajnoczi wrote: > The Big QEMU Lock (BQL) has many names and they are confusing. The > actual QemuMutex variable is called qemu_global_mutex but it's > commonly > referred to as the BQL in discussions and some code comments. The > locking APIs, however, are called qemu_mutex_lock_iothread() and > qemu_mutex_unlock_iothread(). > > The "iothread" name is historic and comes from when the main thread > was > split into into KVM vcpu threads and the "iothread" (now called the > main > loop thread). I have contributed to the confusion myself by > introducing > a separate --object iothread, a separate concept unrelated to the > BQL. > > The "iothread" name is no longer appropriate for the BQL. Rename the > locking APIs to: > - void qemu_bql_lock(void) > - void qemu_bql_unlock(void) > - bool qemu_bql_locked(void) > > There are more APIs with "iothread" in their names. Subsequent > patches > will rename them. There are also comments and documentation that will > be > updated in later patches. > > Signed-off-by: Stefan Hajnoczi Acked-by: Eric Farman
Re: [PATCH 1/6] system/cpus: rename qemu_mutex_lock_iothread() to qemu_bql_lock()
Hi Stefan, On 11/30/23 02:56, Stefan Hajnoczi wrote: The Big QEMU Lock (BQL) has many names and they are confusing. The actual QemuMutex variable is called qemu_global_mutex but it's commonly referred to as the BQL in discussions and some code comments. The locking APIs, however, are called qemu_mutex_lock_iothread() and qemu_mutex_unlock_iothread(). The "iothread" name is historic and comes from when the main thread was split into into KVM vcpu threads and the "iothread" (now called the main loop thread). I have contributed to the confusion myself by introducing a separate --object iothread, a separate concept unrelated to the BQL. The "iothread" name is no longer appropriate for the BQL. Rename the locking APIs to: - void qemu_bql_lock(void) - void qemu_bql_unlock(void) - bool qemu_bql_locked(void) There are more APIs with "iothread" in their names. Subsequent patches will rename them. There are also comments and documentation that will be updated in later patches. Signed-off-by: Stefan Hajnoczi --- include/block/aio-wait.h | 2 +- include/qemu/main-loop.h | 26 +++--- accel/accel-blocker.c| 10 +-- accel/dummy-cpus.c | 8 +- accel/hvf/hvf-accel-ops.c| 4 +- accel/kvm/kvm-accel-ops.c| 4 +- accel/kvm/kvm-all.c | 22 ++--- accel/tcg/cpu-exec.c | 26 +++--- accel/tcg/cputlb.c | 16 ++-- accel/tcg/tcg-accel-ops-icount.c | 4 +- accel/tcg/tcg-accel-ops-mttcg.c | 12 +-- accel/tcg/tcg-accel-ops-rr.c | 14 ++-- accel/tcg/tcg-accel-ops.c| 2 +- accel/tcg/translate-all.c| 2 +- cpu-common.c | 4 +- dump/dump.c | 4 +- hw/core/cpu-common.c | 6 +- hw/i386/intel_iommu.c| 6 +- hw/i386/kvm/xen_evtchn.c | 16 ++-- hw/i386/kvm/xen_overlay.c| 2 +- hw/i386/kvm/xen_xenstore.c | 2 +- hw/intc/arm_gicv3_cpuif.c| 2 +- hw/intc/s390_flic.c | 18 ++-- hw/misc/edu.c| 4 +- hw/misc/imx6_src.c | 2 +- hw/misc/imx7_src.c | 2 +- hw/net/xen_nic.c | 8 +- hw/ppc/pegasos2.c| 2 +- hw/ppc/ppc.c | 4 +- hw/ppc/spapr.c | 2 +- hw/ppc/spapr_rng.c | 4 +- hw/ppc/spapr_softmmu.c | 4 +- hw/remote/mpqemu-link.c | 12 +-- hw/remote/vfio-user-obj.c| 2 +- hw/s390x/s390-skeys.c| 2 +- migration/block-dirty-bitmap.c | 4 +- migration/block.c| 16 ++-- migration/colo.c | 60 +++--- migration/dirtyrate.c| 12 +-- migration/migration.c| 52 ++-- migration/ram.c | 12 +-- replay/replay-internal.c | 2 +- semihosting/console.c| 8 +- stubs/iothread-lock.c| 6 +- system/cpu-throttle.c| 4 +- system/cpus.c| 28 +++ system/dirtylimit.c | 4 +- system/memory.c | 2 +- system/physmem.c | 8 +- system/runstate.c| 2 +- system/watchpoint.c | 4 +- target/arm/arm-powerctl.c| 14 ++-- target/arm/helper.c | 4 +- target/arm/hvf/hvf.c | 8 +- target/arm/kvm.c | 4 +- target/arm/kvm64.c | 4 +- target/arm/ptw.c | 6 +- target/arm/tcg/helper-a64.c | 8 +- target/arm/tcg/m_helper.c| 4 +- target/arm/tcg/op_helper.c | 24 +++--- target/arm/tcg/psci.c| 2 +- target/hppa/int_helper.c | 8 +- target/i386/hvf/hvf.c| 6 +- target/i386/kvm/hyperv.c | 4 +- target/i386/kvm/kvm.c| 28 +++ target/i386/kvm/xen-emu.c| 14 ++-- target/i386/nvmm/nvmm-accel-ops.c| 4 +- target/i386/nvmm/nvmm-all.c | 20 ++--- target/i386/tcg/sysemu/fpu_helper.c | 6 +- target/i386/tcg/sysemu/misc_helper.c | 4 +- target/i386/whpx/whpx-accel-ops.c| 4 +- target/i386/whpx/whpx-all.c | 24 +++--- target/loongarch/csr_helper.c| 4 +- target/mips/kvm.c| 4 +- target/mips/tcg/sysemu/cp0_helper.c | 4 +- target/openrisc/sys_helper.c | 16 ++-- target/ppc/excp_helper.c | 12 +-- target/ppc/kvm.c | 4 +- target/ppc/misc_helper.c | 8 +- target/ppc/timebase_helper.c | 8 +- target/s390x/kvm/kvm.c | 4 +-
Re: [PATCH 1/6] system/cpus: rename qemu_mutex_lock_iothread() to qemu_bql_lock()
On Thu, 30 Nov 2023, Stefan Hajnoczi wrote: On Thu, Nov 30, 2023 at 03:08:49PM -0500, Peter Xu wrote: On Wed, Nov 29, 2023 at 04:26:20PM -0500, Stefan Hajnoczi wrote: The Big QEMU Lock (BQL) has many names and they are confusing. The actual QemuMutex variable is called qemu_global_mutex but it's commonly referred to as the BQL in discussions and some code comments. The locking APIs, however, are called qemu_mutex_lock_iothread() and qemu_mutex_unlock_iothread(). The "iothread" name is historic and comes from when the main thread was split into into KVM vcpu threads and the "iothread" (now called the main loop thread). I have contributed to the confusion myself by introducing a separate --object iothread, a separate concept unrelated to the BQL. The "iothread" name is no longer appropriate for the BQL. Rename the locking APIs to: - void qemu_bql_lock(void) - void qemu_bql_unlock(void) - bool qemu_bql_locked(void) There are more APIs with "iothread" in their names. Subsequent patches will rename them. There are also comments and documentation that will be updated in later patches. Signed-off-by: Stefan Hajnoczi Acked-by: Peter Xu Two nickpicks: - BQL contains "QEMU" as the 2nd character, so maybe easier to further rename qemu_bql into bql_? Philippe wondered whether the variable name should end with _mutex (or _lock is common too), so an alternative might be big_qemu_lock. That's imperfect because it doesn't start with the usual qemu_ prefix. qemu_big_lock is better in that regard but inconsistent with our BQL abbreviation. BQL isn't very specific for those unfamiliar with the code but it's short and already used and known by people so I'm OK with qemu_bql with some comments and docs explainig here and there what bql stands for should be enough for new people to quickly find out. If we want to be more verbose how about "qemu_global_mutex" which is self describing but longer and does not resemble BQL so then comments may be needed to explain this is what was called BQL as well. I don't mind either way though. Regards, BALATON Zoltan I don't like putting an underscore at the end. It's unusual and would make me wonder what that means. Naming is hard, but please discuss and I'm open to change to BQL variable's name to whatever we all agree on. - Could we keep the full spell of BQL at some places, so people can still reference it if not familiar? IIUC most of the BQL helpers will root back to the major three functions (_lock, _unlock, _locked), perhaps add a comment of "BQL stands for..." over these three functions as comment? Yes, I'll update the doc comments to say "Big QEMU Lock (BQL)" for each of these functions. Stefan
Re: [PATCH 1/6] system/cpus: rename qemu_mutex_lock_iothread() to qemu_bql_lock()
On Thu, Nov 30, 2023 at 03:43:25PM -0500, Stefan Hajnoczi wrote: > On Thu, Nov 30, 2023 at 03:08:49PM -0500, Peter Xu wrote: > > On Wed, Nov 29, 2023 at 04:26:20PM -0500, Stefan Hajnoczi wrote: > > > The Big QEMU Lock (BQL) has many names and they are confusing. The > > > actual QemuMutex variable is called qemu_global_mutex but it's commonly > > > referred to as the BQL in discussions and some code comments. The > > > locking APIs, however, are called qemu_mutex_lock_iothread() and > > > qemu_mutex_unlock_iothread(). > > > > > > The "iothread" name is historic and comes from when the main thread was > > > split into into KVM vcpu threads and the "iothread" (now called the main > > > loop thread). I have contributed to the confusion myself by introducing > > > a separate --object iothread, a separate concept unrelated to the BQL. > > > > > > The "iothread" name is no longer appropriate for the BQL. Rename the > > > locking APIs to: > > > - void qemu_bql_lock(void) > > > - void qemu_bql_unlock(void) > > > - bool qemu_bql_locked(void) > > > > > > There are more APIs with "iothread" in their names. Subsequent patches > > > will rename them. There are also comments and documentation that will be > > > updated in later patches. > > > > > > Signed-off-by: Stefan Hajnoczi > > > > Acked-by: Peter Xu > > > > Two nickpicks: > > > > - BQL contains "QEMU" as the 2nd character, so maybe easier to further > > rename qemu_bql into bql_? > > Philippe wondered whether the variable name should end with _mutex (or > _lock is common too), so an alternative might be big_qemu_lock. That's IMHO mutex isn't important in this context, but an implementation detail of the "lock" as an abstract concept. For example, we won't need to rename it again then if the impl changes, e.g. using pure futex or a rwlock replacement. When that happens we don't need to change all call sites again. (never really meant to change the lock impl, just an example.. :) KVM actually has that example of KVM_MMU_LOCK() macro taking as the rwlock write lock when the spinlock is replaced with rwlock, while it'll keep to be the spinlock "lock()" when !KVM_HAVE_MMU_RWLOCK. > imperfect because it doesn't start with the usual qemu_ prefix. > qemu_big_lock is better in that regard but inconsistent with our BQL > abbreviation. > > I don't like putting an underscore at the end. It's unusual and would > make me wonder what that means. Ah, I meant replacing the "qemu_bql_" prefix with "bql_", as that contains QEMU already, rather than making "_" at the end. So they'll be bql_lock(), bql_unlock(), bql_locked(). > > Naming is hard, but please discuss and I'm open to change to BQL > variable's name to whatever we all agree on. I'm pretty okay with qemu_bql_lock(), etc. too. I prefer a tiny little bit on bql_ over qemu_bql_ in this regard, but frankly they're all names good enough to me. The "qemu_" prefix can still be a good thing saying "this is a qemu global function", even if contained inside "bql" itself. > > > > > - Could we keep the full spell of BQL at some places, so people can still > > reference it if not familiar? IIUC most of the BQL helpers will root > > back to the major three functions (_lock, _unlock, _locked), perhaps > > add a comment of "BQL stands for..." over these three functions as > > comment? > > Yes, I'll update the doc comments to say "Big QEMU Lock (BQL)" for each > of these functions. Thanks! -- Peter Xu
Re: [PATCH 1/6] system/cpus: rename qemu_mutex_lock_iothread() to qemu_bql_lock()
On Thu, Nov 30, 2023 at 03:08:49PM -0500, Peter Xu wrote: > On Wed, Nov 29, 2023 at 04:26:20PM -0500, Stefan Hajnoczi wrote: > > The Big QEMU Lock (BQL) has many names and they are confusing. The > > actual QemuMutex variable is called qemu_global_mutex but it's commonly > > referred to as the BQL in discussions and some code comments. The > > locking APIs, however, are called qemu_mutex_lock_iothread() and > > qemu_mutex_unlock_iothread(). > > > > The "iothread" name is historic and comes from when the main thread was > > split into into KVM vcpu threads and the "iothread" (now called the main > > loop thread). I have contributed to the confusion myself by introducing > > a separate --object iothread, a separate concept unrelated to the BQL. > > > > The "iothread" name is no longer appropriate for the BQL. Rename the > > locking APIs to: > > - void qemu_bql_lock(void) > > - void qemu_bql_unlock(void) > > - bool qemu_bql_locked(void) > > > > There are more APIs with "iothread" in their names. Subsequent patches > > will rename them. There are also comments and documentation that will be > > updated in later patches. > > > > Signed-off-by: Stefan Hajnoczi > > Acked-by: Peter Xu > > Two nickpicks: > > - BQL contains "QEMU" as the 2nd character, so maybe easier to further > rename qemu_bql into bql_? Philippe wondered whether the variable name should end with _mutex (or _lock is common too), so an alternative might be big_qemu_lock. That's imperfect because it doesn't start with the usual qemu_ prefix. qemu_big_lock is better in that regard but inconsistent with our BQL abbreviation. I don't like putting an underscore at the end. It's unusual and would make me wonder what that means. Naming is hard, but please discuss and I'm open to change to BQL variable's name to whatever we all agree on. > > - Could we keep the full spell of BQL at some places, so people can still > reference it if not familiar? IIUC most of the BQL helpers will root > back to the major three functions (_lock, _unlock, _locked), perhaps > add a comment of "BQL stands for..." over these three functions as > comment? Yes, I'll update the doc comments to say "Big QEMU Lock (BQL)" for each of these functions. Stefan signature.asc Description: PGP signature
Re: [PATCH 1/6] system/cpus: rename qemu_mutex_lock_iothread() to qemu_bql_lock()
On Wed, Nov 29, 2023 at 04:26:20PM -0500, Stefan Hajnoczi wrote: > The Big QEMU Lock (BQL) has many names and they are confusing. The > actual QemuMutex variable is called qemu_global_mutex but it's commonly > referred to as the BQL in discussions and some code comments. The > locking APIs, however, are called qemu_mutex_lock_iothread() and > qemu_mutex_unlock_iothread(). > > The "iothread" name is historic and comes from when the main thread was > split into into KVM vcpu threads and the "iothread" (now called the main > loop thread). I have contributed to the confusion myself by introducing > a separate --object iothread, a separate concept unrelated to the BQL. > > The "iothread" name is no longer appropriate for the BQL. Rename the > locking APIs to: > - void qemu_bql_lock(void) > - void qemu_bql_unlock(void) > - bool qemu_bql_locked(void) > > There are more APIs with "iothread" in their names. Subsequent patches > will rename them. There are also comments and documentation that will be > updated in later patches. > > Signed-off-by: Stefan Hajnoczi Acked-by: Peter Xu Two nickpicks: - BQL contains "QEMU" as the 2nd character, so maybe easier to further rename qemu_bql into bql_? - Could we keep the full spell of BQL at some places, so people can still reference it if not familiar? IIUC most of the BQL helpers will root back to the major three functions (_lock, _unlock, _locked), perhaps add a comment of "BQL stands for..." over these three functions as comment? Please take or ignore these nitpicks; my ACK will stand irrelevant. Thanks, -- Peter Xu
Re: [PATCH 1/6] system/cpus: rename qemu_mutex_lock_iothread() to qemu_bql_lock()
On 11/29/23 22:26, Stefan Hajnoczi wrote: The Big QEMU Lock (BQL) has many names and they are confusing. The actual QemuMutex variable is called qemu_global_mutex but it's commonly referred to as the BQL in discussions and some code comments. The locking APIs, however, are called qemu_mutex_lock_iothread() and qemu_mutex_unlock_iothread(). The "iothread" name is historic and comes from when the main thread was split into into KVM vcpu threads and the "iothread" (now called the main loop thread). I have contributed to the confusion myself by introducing a separate --object iothread, a separate concept unrelated to the BQL. The "iothread" name is no longer appropriate for the BQL. Rename the locking APIs to: - void qemu_bql_lock(void) - void qemu_bql_unlock(void) - bool qemu_bql_locked(void) There are more APIs with "iothread" in their names. Subsequent patches will rename them. There are also comments and documentation that will be updated in later patches. Signed-off-by: Stefan Hajnoczi Reviewed-by: Cédric Le Goater Thanks, C.
Re: [PATCH 1/6] system/cpus: rename qemu_mutex_lock_iothread() to qemu_bql_lock()
On Wed, 2023-11-29 at 16:26 -0500, Stefan Hajnoczi wrote: > The Big QEMU Lock (BQL) has many names and they are confusing. The > actual QemuMutex variable is called qemu_global_mutex but it's commonly > referred to as the BQL in discussions and some code comments. The > locking APIs, however, are called qemu_mutex_lock_iothread() and > qemu_mutex_unlock_iothread(). > > The "iothread" name is historic and comes from when the main thread was > split into into KVM vcpu threads and the "iothread" (now called the main > loop thread). I have contributed to the confusion myself by introducing > a separate --object iothread, a separate concept unrelated to the BQL. > > The "iothread" name is no longer appropriate for the BQL. Rename the > locking APIs to: > - void qemu_bql_lock(void) > - void qemu_bql_unlock(void) > - bool qemu_bql_locked(void) > > There are more APIs with "iothread" in their names. Subsequent patches > will rename them. There are also comments and documentation that will be > updated in later patches. > > Signed-off-by: Stefan Hajnoczi Acked-by: David Woodhouse smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 1/6] system/cpus: rename qemu_mutex_lock_iothread() to qemu_bql_lock()
Stefan Hajnoczi writes: > The Big QEMU Lock (BQL) has many names and they are confusing. The > actual QemuMutex variable is called qemu_global_mutex but it's commonly > referred to as the BQL in discussions and some code comments. The > locking APIs, however, are called qemu_mutex_lock_iothread() and > qemu_mutex_unlock_iothread(). > > The "iothread" name is historic and comes from when the main thread was > split into into KVM vcpu threads and the "iothread" (now called the main > loop thread). I have contributed to the confusion myself by introducing > a separate --object iothread, a separate concept unrelated to the BQL. > > The "iothread" name is no longer appropriate for the BQL. Rename the > locking APIs to: > - void qemu_bql_lock(void) > - void qemu_bql_unlock(void) > - bool qemu_bql_locked(void) > > There are more APIs with "iothread" in their names. Subsequent patches > will rename them. There are also comments and documentation that will be > updated in later patches. > > Signed-off-by: Stefan Hajnoczi Acked-by: Fabiano Rosas
Re: [PATCH 1/6] system/cpus: rename qemu_mutex_lock_iothread() to qemu_bql_lock()
On 29/11/2023 21:26, Stefan Hajnoczi wrote: The Big QEMU Lock (BQL) has many names and they are confusing. The actual QemuMutex variable is called qemu_global_mutex but it's commonly referred to as the BQL in discussions and some code comments. The locking APIs, however, are called qemu_mutex_lock_iothread() and qemu_mutex_unlock_iothread(). The "iothread" name is historic and comes from when the main thread was split into into KVM vcpu threads and the "iothread" (now called the main loop thread). I have contributed to the confusion myself by introducing a separate --object iothread, a separate concept unrelated to the BQL. The "iothread" name is no longer appropriate for the BQL. Rename the locking APIs to: - void qemu_bql_lock(void) - void qemu_bql_unlock(void) - bool qemu_bql_locked(void) There are more APIs with "iothread" in their names. Subsequent patches will rename them. There are also comments and documentation that will be updated in later patches. Signed-off-by: Stefan Hajnoczi --- include/block/aio-wait.h | 2 +- include/qemu/main-loop.h | 26 +++--- accel/accel-blocker.c| 10 +-- accel/dummy-cpus.c | 8 +- accel/hvf/hvf-accel-ops.c| 4 +- accel/kvm/kvm-accel-ops.c| 4 +- accel/kvm/kvm-all.c | 22 ++--- accel/tcg/cpu-exec.c | 26 +++--- accel/tcg/cputlb.c | 16 ++-- accel/tcg/tcg-accel-ops-icount.c | 4 +- accel/tcg/tcg-accel-ops-mttcg.c | 12 +-- accel/tcg/tcg-accel-ops-rr.c | 14 ++-- accel/tcg/tcg-accel-ops.c| 2 +- accel/tcg/translate-all.c| 2 +- cpu-common.c | 4 +- dump/dump.c | 4 +- hw/core/cpu-common.c | 6 +- hw/i386/intel_iommu.c| 6 +- hw/i386/kvm/xen_evtchn.c | 16 ++-- hw/i386/kvm/xen_overlay.c| 2 +- hw/i386/kvm/xen_xenstore.c | 2 +- hw/intc/arm_gicv3_cpuif.c| 2 +- hw/intc/s390_flic.c | 18 ++-- hw/misc/edu.c| 4 +- hw/misc/imx6_src.c | 2 +- hw/misc/imx7_src.c | 2 +- hw/net/xen_nic.c | 8 +- hw/ppc/pegasos2.c| 2 +- hw/ppc/ppc.c | 4 +- hw/ppc/spapr.c | 2 +- hw/ppc/spapr_rng.c | 4 +- hw/ppc/spapr_softmmu.c | 4 +- hw/remote/mpqemu-link.c | 12 +-- hw/remote/vfio-user-obj.c| 2 +- hw/s390x/s390-skeys.c| 2 +- migration/block-dirty-bitmap.c | 4 +- migration/block.c| 16 ++-- migration/colo.c | 60 +++--- migration/dirtyrate.c| 12 +-- migration/migration.c| 52 ++-- migration/ram.c | 12 +-- replay/replay-internal.c | 2 +- semihosting/console.c| 8 +- stubs/iothread-lock.c| 6 +- system/cpu-throttle.c| 4 +- system/cpus.c| 28 +++ system/dirtylimit.c | 4 +- system/memory.c | 2 +- system/physmem.c | 8 +- system/runstate.c| 2 +- system/watchpoint.c | 4 +- target/arm/arm-powerctl.c| 14 ++-- target/arm/helper.c | 4 +- target/arm/hvf/hvf.c | 8 +- target/arm/kvm.c | 4 +- target/arm/kvm64.c | 4 +- target/arm/ptw.c | 6 +- target/arm/tcg/helper-a64.c | 8 +- target/arm/tcg/m_helper.c| 4 +- target/arm/tcg/op_helper.c | 24 +++--- target/arm/tcg/psci.c| 2 +- target/hppa/int_helper.c | 8 +- target/i386/hvf/hvf.c| 6 +- target/i386/kvm/hyperv.c | 4 +- target/i386/kvm/kvm.c| 28 +++ target/i386/kvm/xen-emu.c| 14 ++-- target/i386/nvmm/nvmm-accel-ops.c| 4 +- target/i386/nvmm/nvmm-all.c | 20 ++--- target/i386/tcg/sysemu/fpu_helper.c | 6 +- target/i386/tcg/sysemu/misc_helper.c | 4 +- target/i386/whpx/whpx-accel-ops.c| 4 +- target/i386/whpx/whpx-all.c | 24 +++--- target/loongarch/csr_helper.c| 4 +- target/mips/kvm.c| 4 +- target/mips/tcg/sysemu/cp0_helper.c | 4 +- target/openrisc/sys_helper.c | 16 ++-- target/ppc/excp_helper.c | 12 +-- target/ppc/kvm.c | 4 +- target/ppc/misc_helper.c | 8 +- target/ppc/timebase_helper.c | 8 +- target/s390x/kvm/kvm.c | 4 +-
[PATCH 1/6] system/cpus: rename qemu_mutex_lock_iothread() to qemu_bql_lock()
The Big QEMU Lock (BQL) has many names and they are confusing. The actual QemuMutex variable is called qemu_global_mutex but it's commonly referred to as the BQL in discussions and some code comments. The locking APIs, however, are called qemu_mutex_lock_iothread() and qemu_mutex_unlock_iothread(). The "iothread" name is historic and comes from when the main thread was split into into KVM vcpu threads and the "iothread" (now called the main loop thread). I have contributed to the confusion myself by introducing a separate --object iothread, a separate concept unrelated to the BQL. The "iothread" name is no longer appropriate for the BQL. Rename the locking APIs to: - void qemu_bql_lock(void) - void qemu_bql_unlock(void) - bool qemu_bql_locked(void) There are more APIs with "iothread" in their names. Subsequent patches will rename them. There are also comments and documentation that will be updated in later patches. Signed-off-by: Stefan Hajnoczi --- include/block/aio-wait.h | 2 +- include/qemu/main-loop.h | 26 +++--- accel/accel-blocker.c| 10 +-- accel/dummy-cpus.c | 8 +- accel/hvf/hvf-accel-ops.c| 4 +- accel/kvm/kvm-accel-ops.c| 4 +- accel/kvm/kvm-all.c | 22 ++--- accel/tcg/cpu-exec.c | 26 +++--- accel/tcg/cputlb.c | 16 ++-- accel/tcg/tcg-accel-ops-icount.c | 4 +- accel/tcg/tcg-accel-ops-mttcg.c | 12 +-- accel/tcg/tcg-accel-ops-rr.c | 14 ++-- accel/tcg/tcg-accel-ops.c| 2 +- accel/tcg/translate-all.c| 2 +- cpu-common.c | 4 +- dump/dump.c | 4 +- hw/core/cpu-common.c | 6 +- hw/i386/intel_iommu.c| 6 +- hw/i386/kvm/xen_evtchn.c | 16 ++-- hw/i386/kvm/xen_overlay.c| 2 +- hw/i386/kvm/xen_xenstore.c | 2 +- hw/intc/arm_gicv3_cpuif.c| 2 +- hw/intc/s390_flic.c | 18 ++-- hw/misc/edu.c| 4 +- hw/misc/imx6_src.c | 2 +- hw/misc/imx7_src.c | 2 +- hw/net/xen_nic.c | 8 +- hw/ppc/pegasos2.c| 2 +- hw/ppc/ppc.c | 4 +- hw/ppc/spapr.c | 2 +- hw/ppc/spapr_rng.c | 4 +- hw/ppc/spapr_softmmu.c | 4 +- hw/remote/mpqemu-link.c | 12 +-- hw/remote/vfio-user-obj.c| 2 +- hw/s390x/s390-skeys.c| 2 +- migration/block-dirty-bitmap.c | 4 +- migration/block.c| 16 ++-- migration/colo.c | 60 +++--- migration/dirtyrate.c| 12 +-- migration/migration.c| 52 ++-- migration/ram.c | 12 +-- replay/replay-internal.c | 2 +- semihosting/console.c| 8 +- stubs/iothread-lock.c| 6 +- system/cpu-throttle.c| 4 +- system/cpus.c| 28 +++ system/dirtylimit.c | 4 +- system/memory.c | 2 +- system/physmem.c | 8 +- system/runstate.c| 2 +- system/watchpoint.c | 4 +- target/arm/arm-powerctl.c| 14 ++-- target/arm/helper.c | 4 +- target/arm/hvf/hvf.c | 8 +- target/arm/kvm.c | 4 +- target/arm/kvm64.c | 4 +- target/arm/ptw.c | 6 +- target/arm/tcg/helper-a64.c | 8 +- target/arm/tcg/m_helper.c| 4 +- target/arm/tcg/op_helper.c | 24 +++--- target/arm/tcg/psci.c| 2 +- target/hppa/int_helper.c | 8 +- target/i386/hvf/hvf.c| 6 +- target/i386/kvm/hyperv.c | 4 +- target/i386/kvm/kvm.c| 28 +++ target/i386/kvm/xen-emu.c| 14 ++-- target/i386/nvmm/nvmm-accel-ops.c| 4 +- target/i386/nvmm/nvmm-all.c | 20 ++--- target/i386/tcg/sysemu/fpu_helper.c | 6 +- target/i386/tcg/sysemu/misc_helper.c | 4 +- target/i386/whpx/whpx-accel-ops.c| 4 +- target/i386/whpx/whpx-all.c | 24 +++--- target/loongarch/csr_helper.c| 4 +- target/mips/kvm.c| 4 +- target/mips/tcg/sysemu/cp0_helper.c | 4 +- target/openrisc/sys_helper.c | 16 ++-- target/ppc/excp_helper.c | 12 +-- target/ppc/kvm.c | 4 +- target/ppc/misc_helper.c | 8 +- target/ppc/timebase_helper.c | 8 +- target/s390x/kvm/kvm.c | 4 +- target/s390x/tcg/misc_helper.c | 118 +-- target/sparc/int32_helper.c | 2 +-
