Vikram Garhwal <vikram.garh...@amd.com> writes:
> From: Juergen Gross <jgr...@suse.com>
>
> 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 <jgr...@suse.com>
> Reviewed-by: Stefano Stabellini <sstabell...@kernel.org>
> ---
> 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 <alex.ben...@linaro.org>
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
