On Fri, Feb 14, 2025 at 03:40:57PM -0500, Steven Sistare wrote:
> > > diff --git a/system/memory.c b/system/memory.c
> > > index 4c82979..755eafe 100644
> > > --- a/system/memory.c
> > > +++ b/system/memory.c
> > > @@ -2183,9 +2183,8 @@ void
> > > ram_discard_manager_unregister_listener(RamDiscardManager *rdm,
> > > }
> > > /* Called with rcu_read_lock held. */
> > > -bool memory_get_xlat_addr(IOMMUTLBEntry *iotlb, void **vaddr,
> > > - ram_addr_t *ram_addr, bool *read_only,
> > > - bool *mr_has_discard_manager, Error **errp)
> > > +bool memory_get_xlat_addr(IOMMUTLBEntry *iotlb, bool
> > > *mr_has_discard_manager,
> > > + MemoryRegion **mr_p, hwaddr *xlat_p, Error
> > > **errp)
> >
> > If we're going to return the MR anyway, probably we can drop
> > mr_has_discard_manager altogether..
>
> To hoist mr_has_discard_manager to the vfio caller, I would need to return
> len.
> Your call.
I meant only dropping mr_has_discard_manager parameter from the function
interface, not the ram_discard_manager_is_populated() check.
>
> > > {
> > > MemoryRegion *mr;
> > > hwaddr xlat;
> > > @@ -2238,18 +2237,8 @@ bool memory_get_xlat_addr(IOMMUTLBEntry *iotlb,
> > > void **vaddr,
> > > return false;
> > > }
> > > - if (vaddr) {
> > > - *vaddr = memory_region_get_ram_ptr(mr) + xlat;
> > > - }
> > > -
> > > - if (ram_addr) {
> > > - *ram_addr = memory_region_get_ram_addr(mr) + xlat;
> > > - }
> > > -
> > > - if (read_only) {
> > > - *read_only = !writable || mr->readonly;
> > > - }
> > > -
> > > + *xlat_p = xlat;
> > > + *mr_p = mr;
> >
> > I suppose current use on the callers are still under RCU so looks ok, but
> > that'll need to be rich-documented.
>
> I can do that, or ...
>
> > Better way is always taking a MR reference when the MR pointer is returned,
> > with memory_region_ref(). Then it is even valid if by accident accessed
> > after rcu_read_unlock(), and caller should unref() after use.
>
> I can do that, but it would add cycles. Is this considered a high performance
> path that may be called frequently?
AFAICT, any vIOMMU mapping isn't high perf path. In this specific path,
the refcount op should be buried in any dma map operations..
Personally I slightly prefer this one because it's always safer to take a
refcount along with a pointer.. easier to follow.
--
Peter Xu