This patch brings back Jan's idea [1] of BQL-free IO access
This will let us make access to ACPI PM/HPET timers cheaper,
and prevent BQL contention in case of workload that heavily
uses the timers with a lot of vCPUs.
1) 196ea13104f (memory: Add global-locking property to memory regions)
... de7ea885c539 (kvm: Switch to unlocked MMIO)
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
---
include/system/memory.h | 10 ++++++++++
system/memory.c | 6 ++++++
system/physmem.c | 2 +-
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/include/system/memory.h b/include/system/memory.h
index e2cd6ed126..d04366c994 100644
--- a/include/system/memory.h
+++ b/include/system/memory.h
@@ -833,6 +833,7 @@ struct MemoryRegion {
bool nonvolatile;
bool rom_device;
bool flush_coalesced_mmio;
+ bool lockless_io;
bool unmergeable;
uint8_t dirty_log_mask;
bool is_iommu;
@@ -2341,6 +2342,15 @@ void memory_region_set_flush_coalesced(MemoryRegion *mr);
*/
void memory_region_clear_flush_coalesced(MemoryRegion *mr);
+/**
+ * memory_region_enable_lockless_io: Enable lockless (BQL free) acceess.
+ *
+ * Enable BQL-free access for devices with fine-grained locking.
+ *
+ * @mr: the memory region to be updated.
+ */
+void memory_region_enable_lockless_io(MemoryRegion *mr);
+
/**
* memory_region_add_eventfd: Request an eventfd to be triggered when a word
* is written to a location.
diff --git a/system/memory.c b/system/memory.c
index 5646547940..9a5a262112 100644
--- a/system/memory.c
+++ b/system/memory.c
@@ -2546,6 +2546,12 @@ void memory_region_clear_flush_coalesced(MemoryRegion *mr)
}
}
+void memory_region_enable_lockless_io(MemoryRegion *mr)
+{
+ mr->lockless_io = true;
+ mr->disable_reentrancy_guard = true;
+}
+
void memory_region_add_eventfd(MemoryRegion *mr,
hwaddr addr,
unsigned size,
diff --git a/system/physmem.c b/system/physmem.c
index 130c148ffb..107871e2b3 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -2909,7 +2909,7 @@ bool prepare_mmio_access(MemoryRegion *mr)
{
bool release_lock = false;
- if (!bql_locked()) {
+ if (!bql_locked() && !mr->lockless_io) {
bql_lock();
release_lock = true;
}
--
2.47.1
On Wed, Jul 30, 2025 at 02:39:29PM +0200, Igor Mammedov wrote:
> diff --git a/system/memory.c b/system/memory.c
> index 5646547940..9a5a262112 100644
> --- a/system/memory.c
> +++ b/system/memory.c
> @@ -2546,6 +2546,12 @@ void memory_region_clear_flush_coalesced(MemoryRegion *mr)
> }
> }
>
> +void memory_region_enable_lockless_io(MemoryRegion *mr)
> +{
> + mr->lockless_io = true;
> + mr->disable_reentrancy_guard = true;
IIUC this is needed only because the re-entrancy guard is not
per-transaction but per-device, am I right?
Maybe some comment would be nice here to explain how mmio concurrency could
affect this. If my above comment is correct, it could also be a TODO so we
could re-enable this when it is per-transaction (even though I don't know
whether it's easy / useful to do..).
Thanks,
--
Peter Xu
On Wed, 30 Jul 2025 17:47:52 -0400
Peter Xu <peterx@redhat.com> wrote:
> On Wed, Jul 30, 2025 at 02:39:29PM +0200, Igor Mammedov wrote:
> > diff --git a/system/memory.c b/system/memory.c
> > index 5646547940..9a5a262112 100644
> > --- a/system/memory.c
> > +++ b/system/memory.c
> > @@ -2546,6 +2546,12 @@ void memory_region_clear_flush_coalesced(MemoryRegion *mr)
> > }
> > }
> >
> > +void memory_region_enable_lockless_io(MemoryRegion *mr)
> > +{
> > + mr->lockless_io = true;
/*
* reentrancy_guard has per device scope, that when enabled
* will effectively prevent concurrent access to device's IO
* MemoryRegion(s) by not calling accessor callback.
*
* Turn it off for lock-less IO enabled devices, to allow
* concurrent IO.
* TODO: remove this when reentrancy_guard becomes per transaction.
*/
would something like this be sufficient?
> > + mr->disable_reentrancy_guard = true;
>
> IIUC this is needed only because the re-entrancy guard is not
> per-transaction but per-device, am I right?
>
> Maybe some comment would be nice here to explain how mmio concurrency could
> affect this. If my above comment is correct, it could also be a TODO so we
> could re-enable this when it is per-transaction (even though I don't know
> whether it's easy / useful to do..).
>
> Thanks,
>
On Fri, Aug 01, 2025 at 02:42:26PM +0200, Igor Mammedov wrote:
> On Wed, 30 Jul 2025 17:47:52 -0400
> Peter Xu <peterx@redhat.com> wrote:
>
> > On Wed, Jul 30, 2025 at 02:39:29PM +0200, Igor Mammedov wrote:
> > > diff --git a/system/memory.c b/system/memory.c
> > > index 5646547940..9a5a262112 100644
> > > --- a/system/memory.c
> > > +++ b/system/memory.c
> > > @@ -2546,6 +2546,12 @@ void memory_region_clear_flush_coalesced(MemoryRegion *mr)
> > > }
> > > }
> > >
> > > +void memory_region_enable_lockless_io(MemoryRegion *mr)
> > > +{
> > > + mr->lockless_io = true;
>
> /*
> * reentrancy_guard has per device scope, that when enabled
> * will effectively prevent concurrent access to device's IO
> * MemoryRegion(s) by not calling accessor callback.
> *
> * Turn it off for lock-less IO enabled devices, to allow
> * concurrent IO.
> * TODO: remove this when reentrancy_guard becomes per transaction.
> */
>
> would something like this be sufficient?
Looks good to me, thanks!
--
Peter Xu
On Wed, 30 Jul 2025 17:47:52 -0400
Peter Xu <peterx@redhat.com> wrote:
> On Wed, Jul 30, 2025 at 02:39:29PM +0200, Igor Mammedov wrote:
> > diff --git a/system/memory.c b/system/memory.c
> > index 5646547940..9a5a262112 100644
> > --- a/system/memory.c
> > +++ b/system/memory.c
> > @@ -2546,6 +2546,12 @@ void memory_region_clear_flush_coalesced(MemoryRegion *mr)
> > }
> > }
> >
> > +void memory_region_enable_lockless_io(MemoryRegion *mr)
> > +{
> > + mr->lockless_io = true;
> > + mr->disable_reentrancy_guard = true;
>
> IIUC this is needed only because the re-entrancy guard is not
> per-transaction but per-device, am I right?
As far as I understood, it was per memory region (device in this case).
> Maybe some comment would be nice here to explain how mmio concurrency could
> affect this. If my above comment is correct, it could also be a TODO so we
> could re-enable this when it is per-transaction (even though I don't know
> whether it's easy / useful to do..).
I can add a comment on repin.
>
> Thanks,
>
© 2016 - 2025 Red Hat, Inc.