On Fri, 8 Aug 2025 17:24:54 +0200 David Hildenbrand <[email protected]> wrote:
> On 08.08.25 16:36, Igor Mammedov wrote: > > On Fri, 8 Aug 2025 14:12:54 +0200 > > David Hildenbrand <[email protected]> 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 <[email protected]> > >>> --- > >>> v3: > >>> add comment for 'mr->disable_reentrancy_guard = true' > >>> Peter Xu <[email protected]> > >>> --- > >>> 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." Thank, I'll fix it up on respin > > Nothing else jumped at me. >
