[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/5] common/vmap: Fall back to simple allocator when !HAS_VMAP


  • To: Luca Fancellu <Luca.Fancellu@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 15 Nov 2024 14:18:09 +0100
  • Autocrypt: addr=jbeulich@xxxxxxxx; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 15 Nov 2024 13:18:21 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 15.11.2024 13:46, Luca Fancellu wrote:
> 
> 
>> On 15 Nov 2024, at 11:12, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>
>> On 15.11.2024 11:50, Luca Fancellu wrote:
>>> --- a/xen/common/vmap.c
>>> +++ b/xen/common/vmap.c
>>> @@ -426,3 +426,10 @@ void *_xvrealloc(void *va, size_t size, unsigned int 
>>> align)
>>>
>>>     return ptr;
>>> }
>>> +
>>> +void iounmap(void __iomem *va)
>>> +{
>>> +    unsigned long addr = (unsigned long)(void __force *)va;
>>> +
>>> +    vunmap((void *)(addr & PAGE_MASK));
>>> +}
>>
>> Why is this being moved here, and converted from inline to out-of-line?
>> What the description says is insufficient imo, as even if you mean to
>> only support vmap_contig() and ioremap() on MPU systems, you'll still
>> need both vunmap() and iounmap().
>>
>> Plus, if it really needs converting, I don't think it should live at the
>> very end of the file, past _xvmalloc() and friends. Better suitable places
>> may then be next to vunmap() itself, or between vfree() and xvfree().
> 
> I’ll try to keep it as it was originally, I gave a brief look into the R82 
> branch and it should be fine.
> I’m planning to define vmap_config(), vunmap(), ioremap(), iounmap() in a 
> vmap-mpu.c under arch/arm/mpu
> 
>>
>>> --- a/xen/include/xen/vmap.h
>>> +++ b/xen/include/xen/vmap.h
>>> @@ -5,7 +5,7 @@
>>>  * purpose area (VMAP_DEFAULT) and a livepatch-specific area (VMAP_XEN). The
>>>  * latter is used when loading livepatches and the former for everything 
>>> else.
>>>  */
>>> -#if !defined(__XEN_VMAP_H__) && defined(VMAP_VIRT_START)
>>> +#if !defined(__XEN_VMAP_H__)
>>> #define __XEN_VMAP_H__
>>
>> With this adjustment, where are the functions defined that you "unhide"
>> the declarations of, in the MPU case? As you say in the description,
>> vmap.c won't be built in that case.
> 
> Sure, I’ll wrap what can’t be used in MPU case with HAS_VMAP, I would like to 
> keep out:
> 
> void *vmap_contig(mfn_t mfn, unsigned int nr);
> 
> void vunmap(const void *va);
> 
> void __iomem *ioremap(paddr_t pa, size_t len);
> 
> static inline void iounmap(void __iomem *va)
> 
> static inline void vm_init(void)
> 
> In order to don’t put too many #ifdef, are you ok if I move the declarations 
> in order to have these close to each other. like below:

Some re-arrangement ought to be fine, especially when the #ifdef is
accompanied by a comment. I can't see how there can be #else though.

Jan

> --- a/xen/include/xen/vmap.h
> +++ b/xen/include/xen/vmap.h
> @@ -11,6 +11,8 @@
>  #include <xen/mm-frame.h>
>  #include <xen/page-size.h>
>  
> +#ifdef CONFIG_HAS_VMAP
> +
>  /* Identifiers for the linear ranges tracked by vmap */
>  enum vmap_region {
>      /*
> @@ -68,25 +70,6 @@ void *__vmap(const mfn_t *mfn, unsigned int granularity, 
> unsigned int nr,
>   */
>  void *vmap(const mfn_t *mfn, unsigned int nr);
>  
> -/*
> - * Maps physically contiguous pages onto the VMAP_DEFAULT vmap region
> - *
> - * @param mfn Base mfn of the physical region
> - * @param nr  Number of mfns in the physical region
> - * @return Pointer to the mapped area on success; NULL otherwise.
> - */
> -void *vmap_contig(mfn_t mfn, unsigned int nr);
> -
> -/*
> - * Unmaps a range of virtually contiguous memory from one of the vmap regions
> - *
> - * The system remembers internally how wide the mapping is and unmaps it all.
> - * It also can determine the vmap region type from the `va`.
> - *
> - * @param va Virtual base address of the range to unmap
> - */
> -void vunmap(const void *va);
> -
>  /*
>   * Allocate `size` octets of possibly non-contiguous physical memory and map
>   * them contiguously in the VMAP_DEFAULT vmap region
> @@ -112,6 +95,33 @@ void *vzalloc(size_t size);
>   */
>  void vfree(void *va);
>  
> +/* Return the number of pages in the mapping starting at address 'va' */
> +unsigned int vmap_size(const void *va);
> +
> +/* Pointer to 1 octet past the end of the VMAP_DEFAULT virtual area */
> +void *arch_vmap_virt_end(void);
> +
> +#else /* !CONFIG_HAS_VMAP */
> +
> +/*
> + * Maps physically contiguous pages onto the VMAP_DEFAULT vmap region
> + *
> + * @param mfn Base mfn of the physical region
> + * @param nr  Number of mfns in the physical region
> + * @return Pointer to the mapped area on success; NULL otherwise.
> + */
> +void *vmap_contig(mfn_t mfn, unsigned int nr);
> +
> +/*
> + * Unmaps a range of virtually contiguous memory from one of the vmap regions
> + *
> + * The system remembers internally how wide the mapping is and unmaps it all.
> + * It also can determine the vmap region type from the `va`.
> + *
> + * @param va Virtual base address of the range to unmap
> + */
> +void vunmap(const void *va);
> +
>  /*
>   * Analogous to vmap_contig(), but for IO memory
>   *
> @@ -124,9 +134,6 @@ void vfree(void *va);
>   */
>  void __iomem *ioremap(paddr_t pa, size_t len);
>  
> -/* Return the number of pages in the mapping starting at address 'va' */
> -unsigned int vmap_size(const void *va);
> -
>  /* Analogous to vunmap(), but for IO memory mapped via ioremap() */
>  static inline void iounmap(void __iomem *va)
>  {
> @@ -135,9 +142,6 @@ static inline void iounmap(void __iomem *va)
>      vunmap((void *)(addr & PAGE_MASK));
>  }
>  
> -/* Pointer to 1 octet past the end of the VMAP_DEFAULT virtual area */
> -void *arch_vmap_virt_end(void);
> -
>  /* Initialises the VMAP_DEFAULT virtual range */
>  static inline void vm_init(void)
>  {
> @@ -146,4 +150,6 @@ static inline void vm_init(void)
>  #endif
>  }
>  
> +#endif /* CONFIG_HAS_VMAP */
> +
>  #endif /* __XEN_VMAP_H__ */




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.