On 08.08.25 16:36, Igor Mammedov wrote:
On Fri, 8 Aug 2025 14:12:54 +0200
David Hildenbrand <da...@redhat.com> wrote:
On 08.08.25 14:01, Igor Mammedov wrote:
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 <imamm...@redhat.com>
---
v3:
add comment for 'mr->disable_reentrancy_guard = true'
Peter Xu <pet...@redhat.com>
---
include/system/memory.h | 10 ++++++++++
system/memory.c | 15 +++++++++++++++
system/physmem.c | 2 +-
3 files changed, 26 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);
Is this safe to use on any IO region, or could actually something break
when mis-used? In case it's the latter, I assume we would want to
carefully document under which scenarios this is safe to use.
"for devices with fine-grained locking" is defining scope of where it's
applicable, in another words devices enabling this need to take care
of any locking if necessary.
Okay, I would have stressed that a bit more, something like
"Enable BQL-free access for devices that are well prepared to handle
locking during I/O themselves: either by doing fine grained locking or
by providing lock-free I/O schemes."
Nothing else jumped at me.
--
Cheers,
David / dhildenb
