Re: [PATCH v3 01/10] memory: reintroduce BQL-free fine-grained PIO/MMIO

[Igor Mammedov <imammedo@redhat.com>]

On Fri, 8 Aug 2025 14:12:54 +0200
David Hildenbrand <david@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 <imammedo@redhat.com>
> > ---
> > v3:
> >    add comment for 'mr->disable_reentrancy_guard = true'
> >      Peter Xu <peterx@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.

in this series PM timer didn't need any, while HPET required
some refactoring to make it lock-less on main timer reads,
while taking per device lock for everything else.