On Fri, Mar 1, 2024 at 6:08 PM Alex Bennée <[email protected]> wrote:
> Vikram Garhwal <[email protected]> writes: > > > From: Juergen Gross <[email protected]> > > > > Today xen_ram_addr_from_mapcache() will either abort() or return 0 in > > case it can't find a matching entry for a pointer value. Both cases > > are bad, so change that to return an invalid address instead. > > > > Signed-off-by: Juergen Gross <[email protected]> > > Reviewed-by: Stefano Stabellini <[email protected]> > > --- > > hw/xen/xen-mapcache.c | 11 +++-------- > > 1 file changed, 3 insertions(+), 8 deletions(-) > > > > diff --git a/hw/xen/xen-mapcache.c b/hw/xen/xen-mapcache.c > > index dfc412d138..179b7e95b2 100644 > > --- a/hw/xen/xen-mapcache.c > > +++ b/hw/xen/xen-mapcache.c > > @@ -396,13 +396,8 @@ ram_addr_t xen_ram_addr_from_mapcache(void *ptr) > > } > > } > > if (!found) { > > - trace_xen_ram_addr_from_mapcache_not_found(ptr); > > - QTAILQ_FOREACH(reventry, &mapcache->locked_entries, next) { > > - > trace_xen_ram_addr_from_mapcache_found(reventry->paddr_index, > > - reventry->vaddr_req); > > - } > > If these tracepoints aren't useful they need removing from trace-events. > However I suspect it would be better to keep them in as they are fairly > cheap. > > Otherwise: > > Reviewed-by: Alex Bennée <[email protected]> > > Reviewed-by: Edgar E. Iglesias <[email protected]>
