Re: [Xen-devel] [PATCH v5 14/18] x86/mem_sharing: use default_access in add_to_physmap

[Jan Beulich <jbeulich@xxxxxxxx>]

On 21.01.2020 18:49, Tamas K Lengyel wrote:
> When plugging a hole in the target physmap don't use the access permission
> returned by __get_gfn_type_access as it can be non-sensical,

"can be" is too vague for my taste - it suggests there may also be cases
where a sensible value is returned, and hence it should be used. Could
you clarify this please? (The code change itself of course is simple and
mechanical enough to look okay.)

Jan

> leading to
> spurious vm_events being sent out for access violations at unexpected
> locations. Make use of p2m->default_access instead.
> 
> Signed-off-by: Tamas K Lengyel <tamas.lengyel@xxxxxxxxx>
> ---
>  xen/arch/x86/mm/mem_sharing.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
> index eac8047c07..e3ddb63b4f 100644
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -1071,11 +1071,10 @@ int add_to_physmap(struct domain *sd, unsigned long 
> sgfn, shr_handle_t sh,
>      p2m_type_t smfn_type, cmfn_type;
>      struct gfn_info *gfn_info;
>      struct p2m_domain *p2m = p2m_get_hostp2m(cd);
> -    p2m_access_t a;
>      struct two_gfns tg;
>  
>      get_two_gfns(sd, _gfn(sgfn), &smfn_type, NULL, &smfn,
> -                 cd, _gfn(cgfn), &cmfn_type, &a, &cmfn, 0, &tg, lock);
> +                 cd, _gfn(cgfn), &cmfn_type, NULL, &cmfn, 0, &tg, lock);
>  
>      /* Get the source shared page, check and lock */
>      ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
> @@ -1110,7 +1109,7 @@ int add_to_physmap(struct domain *sd, unsigned long 
> sgfn, shr_handle_t sh,
>      }
>  
>      ret = p2m_set_entry(p2m, _gfn(cgfn), smfn, PAGE_ORDER_4K,
> -                        p2m_ram_shared, a);
> +                        p2m_ram_shared, p2m->default_access);
>  
>      /* Tempted to turn this into an assert */
>      if ( ret )
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel