include: make domain_page.h's stubs properly use type-unsafe MFN <-> virt helpers

[PATCH] include: make domain_page.h's stubs properly use type-unsafe MFN <-> virt helpers

Posted by Jan Beulich 2 weeks, 2 days ago

The first of the commits referenced below didn't go far enough, and the
2nd of them, while trying to close (some of) the gap, wrongly kept using
the potentially type-safe variant. This is getting in the way of new
ports preferably not having any type-unsafe private code (and in
particular not having a need for any overrides in newly introduced
files).

Fixes: 41c48004d1d8 ("xen/mm: Use __virt_to_mfn in map_domain_page instead of virt_to_mfn")
Fixes: f46b6197344f ("xen: Convert page_to_mfn and mfn_to_page to use typesafe MFN")
Reported-by: Shawn Anastasio <sanastasio@raptorengineering.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/include/xen/domain_page.h
+++ b/xen/include/xen/domain_page.h
@@ -56,11 +56,11 @@ static inline void *__map_domain_page_gl
 #define map_domain_page(mfn)                __mfn_to_virt(mfn_x(mfn))
 #define __map_domain_page(pg)               page_to_virt(pg)
 #define unmap_domain_page(va)               ((void)(va))
-#define domain_page_map_to_mfn(va)          _mfn(virt_to_mfn((unsigned long)(va)))
+#define domain_page_map_to_mfn(va)          _mfn(__virt_to_mfn((unsigned long)(va)))
 
 static inline void *map_domain_page_global(mfn_t mfn)
 {
-    return mfn_to_virt(mfn_x(mfn));
+    return __mfn_to_virt(mfn_x(mfn));
 }
 
 static inline void *__map_domain_page_global(const struct page_info *pg)

Re: [PATCH] include: make domain_page.h's stubs properly use type-unsafe MFN <-> virt helpers

Posted by Shawn Anastasio 2 weeks, 1 day ago

On 9/11/23 1:38 AM, Jan Beulich wrote:
> The first of the commits referenced below didn't go far enough, and the
> 2nd of them, while trying to close (some of) the gap, wrongly kept using
> the potentially type-safe variant. This is getting in the way of new
> ports preferably not having any type-unsafe private code (and in
> particular not having a need for any overrides in newly introduced
> files).
> 
> Fixes: 41c48004d1d8 ("xen/mm: Use __virt_to_mfn in map_domain_page instead of virt_to_mfn")
> Fixes: f46b6197344f ("xen: Convert page_to_mfn and mfn_to_page to use typesafe MFN")
> Reported-by: Shawn Anastasio <sanastasio@raptorengineering.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/include/xen/domain_page.h
> +++ b/xen/include/xen/domain_page.h
> @@ -56,11 +56,11 @@ static inline void *__map_domain_page_gl
>  #define map_domain_page(mfn)                __mfn_to_virt(mfn_x(mfn))
>  #define __map_domain_page(pg)               page_to_virt(pg)
>  #define unmap_domain_page(va)               ((void)(va))
> -#define domain_page_map_to_mfn(va)          _mfn(virt_to_mfn((unsigned long)(va)))
> +#define domain_page_map_to_mfn(va)          _mfn(__virt_to_mfn((unsigned long)(va)))
>  
>  static inline void *map_domain_page_global(mfn_t mfn)
>  {
> -    return mfn_to_virt(mfn_x(mfn));
> +    return __mfn_to_virt(mfn_x(mfn));
>  }
>  
>  static inline void *__map_domain_page_global(const struct page_info *pg)

Reviewed-by: Shawn Anastasio <sanastasio@raptorengineering.com>

Thanks,
Shawn

Re: [PATCH] include: make domain_page.h's stubs properly use type-unsafe MFN <-> virt helpers

Posted by Julien Grall 2 weeks, 2 days ago

Hi Jan,

On 11/09/2023 07:38, Jan Beulich wrote:
> The first of the commits referenced below didn't go far enough, and the
> 2nd of them, while trying to close (some of) the gap, wrongly kept using
> the potentially type-safe variant. This is getting in the way of new
> ports preferably not having any type-unsafe private code (and in
> particular not having a need for any overrides in newly introduced
> files).
> 
> Fixes: 41c48004d1d8 ("xen/mm: Use __virt_to_mfn in map_domain_page instead of virt_to_mfn")
> Fixes: f46b6197344f ("xen: Convert page_to_mfn and mfn_to_page to use typesafe MFN")
> Reported-by: Shawn Anastasio <sanastasio@raptorengineering.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Julien Grall <jgrall@amazon.com>

Cheers,

-- 
Julien Grall