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

Re: [PATCH v5 12/13] xen/arm: mmu: relocate copy_from_paddr() to setup.c


  • To: Julien Grall <julien@xxxxxxx>
  • From: Henry Wang <Henry.Wang@xxxxxxx>
  • Date: Tue, 22 Aug 2023 08:54:37 +0000
  • Accept-language: zh-CN, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/1IU4sh8/CsRI3M3MS7RVasmjwTq6WStyqHwtlmO85U=; b=T/CTJDCxxkysA/HsWVoNlnyt/DuNbOJk+dhOCvPpW3Zl+Iviigh0uYEpAbXNE468WShdbOVMRgGGxal7NJtuvO8Zcj8Pwsm5i1ud5s6qSW5qGbjewAY0SUXTjMuLB/FMqrR7w72P7yyzfl2ldOb4lwovosvNnuLtQPO41LMmJWU+jX4DEY1BhFOCDfulv9SuT9sFUj7M1NQCpz9alE/CG/XUv2vbT7hzRwCPhI5d0aC8IjdcR05YU8J/8hXSrchKW/mRivxY6eBgDM4clUvq+DjR5XO144pQAol7EHahSR1Hue4q1+EadJSYHrPyO4PoJ0ELnQvS9grNTPIo7gSSVg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VSimtJd0pGr1CDM10eGFNEXd39WgU4azi5ApbBaeGb2y2kSa/ihGyYeQtdTkKYLO+ViirLq+lLrHjNhZxvJcKPzYV8VDsHKagAkzhCJn7c0G/4JfYsdwSWk4PdxYA/K8ByOZu0Ix7KTy8PdQgCyeZ+tj5KH1JVpx85rEB99kP9nZ1EsqjshYZO+A95APlEyjrymkLWCQsfcOMy2Nlk+HaDppBCv8JgvL4GQlw8ABHZPBQj3mrN0FKBCPLdUAWUb2esVdcbojZ7MPosfo+uUNMxNk42UqyNzSnwTTo6ryRUYm070XhT3wFd4YGu6ipIi7e1k80xQgMSbwwC/w7Culfg==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Penny Zheng <Penny.Zheng@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Wei Chen <Wei.Chen@xxxxxxx>
  • Delivery-date: Tue, 22 Aug 2023 08:55:05 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHZzmeOkWUgiqEb9U2fOmI3mEWP3a/1UMEAgACrQQCAABBYAIAAA1gA
  • Thread-topic: [PATCH v5 12/13] xen/arm: mmu: relocate copy_from_paddr() to setup.c

Hi Julien,

> On Aug 22, 2023, at 16:42, Julien Grall <julien@xxxxxxx> wrote:
> 
> On 22/08/2023 08:44, Henry Wang wrote:
>>> On Aug 22, 2023, at 05:31, Julien Grall <julien@xxxxxxx> wrote:
>>> 
>>> Hi,
>>> 
>>> On 14/08/2023 05:25, Henry Wang wrote:
>>>> From: Penny Zheng <Penny.Zheng@xxxxxxx>
>>>> Function copy_from_paddr() is defined in asm/setup.h, so it is better
>>>> to be implemented in setup.c.
>>> 
>>> I don't agree with this reasoning. We used setup.h to declare prototype for 
>>> function that are out of setup.c.
>>> 
>>> Looking at the overall of this series, it is unclear to me what is the 
>>> difference between mmu/mm.c and mmu/setup.c. I know this is technically not 
>>> a new problem but as we split the code, it would be a good opportunity to 
>>> have a better split.
>>> 
>>> For instance, we have setup_mm() defined in setup.c but setup_pagetables() 
>>> and mm.c. Both are technically related to the memory management. So having 
>>> them in separate file is a bit odd.
>> Skimming through the comments, it looks like we have a common problem
>> in patch 7, 9, 10, 12 about how to move/split the code. So instead of having
>> the discussion in each patch, I would like to propose that we can discuss all
>> of these in a common place here.
> 
> +1.
> 
>>> 
>>> I also don't like the idea of having again a massive mm.c files. So maybe 
>>> we need a split like:
>>>  * File 1: Boot CPU0 MM bringup (mmu/setup.c)
>>>  * File 2: Secondary CPUs MM bringup (mmu/smpboot.c)
>>>  * File 3: Page tables update. (mmu/pt.c)
>>> 
>>> Ideally file 1 should contain only init code/data so it can be marked as 
>>> .init. So the static pagetables may want to be defined in mmu/pt.c.
>> So based on Julien’s suggestion, Penny and I worked a bit on the current
>> functions in “arch/arm/mm.c” and we would like to propose below split
>> scheme, would you please comment on if below makes sense to you,
>> thanks!
>> """
>> static void __init __maybe_unused build_assertions()      -> arch/arm/mm.c
> 
> All the existing build assertions seems to be MMU specific. So shouldn't they 
> be moved to mmu/mm.c.
> 
>> static lpae_t *xen_map_table()                            -> mmu/pt.c
>> static void xen_unmap_table()                             -> mmu/pt.c
>> void dump_pt_walk()                                       -> mmu/pt.c
>> void dump_hyp_walk()                                      -> mmu/pt.c
>> lpae_t mfn_to_xen_entry()                                 -> mmu/pt.c
>> void set_fixmap()                                         -> mmu/pt.c
>> void clear_fixmap()                                       -> mmu/pt.c
>> void flush_page_to_ram()                                  -> arch/arm/mm.c?
> 
> I think it should stay in arch/arm/mm.c because you will probably need to 
> clean a page even on MPU systems.
> 
>> lpae_t pte_of_xenaddr()                                   -> mmu/pt.c
>> void * __init early_fdt_map()                             -> mmu/setup.c
>> void __init remove_early_mappings()                       -> mmu/setup.c
>> static void xen_pt_enforce_wnx()                          -> mmu/pt.c, 
>> export it
> 
> AFAIU, it would be called from smpboot.c and setup.c. For the former, the 
> caller is mmu_init_secondary_cpu() which I think can be folded in head.S.
> 
> If we do that, then xen_pt_enforce_wnx() can be moved in setup.c and doesn't 
> need to be exported.
> 
>> static void clear_table()                                 -> mmu/smpboot.c
>> void __init setup_pagetables()                            -> mmu/setup.c
>> static void clear_boot_pagetables()                       -> mmu/smpboot.c
>> int init_secondary_pagetables()                           -> mmu/smpboot.c
>> void mmu_init_secondary_cpu()                             -> mmu/smpboot.c
>> void __init setup_directmap_mappings()                    -> mmu/setup.c
>> void __init setup_frametable_mappings()                   -> mmu/setup.c
>> void *__init arch_vmap_virt_end()                         -> arch/arm/mm.c 
>> or mmu/setup.c?
> 
> AFAIU, the VMAP will not be used for MPU systems. So this would want to go in 
> mmu/. I am ok with setup.c.
> 
>> void *ioremap_attr()                                      -> mmu/pt.c
>> void *ioremap()                                           -> mmu/pt.c
>> static int create_xen_table()                             -> mmu/pt.c
>> static int xen_pt_next_level()                            -> mmu/pt.c
>> static bool xen_pt_check_entry()                          -> mmu/pt.c
>> static int xen_pt_update_entry()                          -> mmu/pt.c
>> static int xen_pt_mapping_level()                         -> mmu/pt.c
>> static unsigned int xen_pt_check_contig()                 -> mmu/pt.c
>> static int xen_pt_update()                                -> mmu/pt.c
>> int map_pages_to_xen()                                    -> mmu/pt.c
>> int __init populate_pt_range()                            -> mmu/pt.c
>> int destroy_xen_mappings()                                -> mmu/pt.c
>> int modify_xen_mappings()                                 -> mmu/pt.c
>> void free_init_memory()                                   -> mmu/setup.c
>> void arch_dump_shared_mem_info()                          -> arch/arm/mm.c
>> int steal_page()                                          -> arch/arm/mm.c
>> int page_is_ram_type()                                    -> arch/arm/mm.c
>> unsigned long domain_get_maximum_gpfn()                   -> arch/arm/mm.c
>> void share_xen_page_with_guest()                          -> arch/arm/mm.c
>> int xenmem_add_to_physmap_one()                           -> arch/arm/mm.c
>> long arch_memory_op()                                     -> arch/arm/mm.c
>> static struct domain *page_get_owner_and_nr_reference()   -> arch/arm/mm.c
>> struct domain *page_get_owner_and_reference()             -> arch/arm/mm.c
>> void put_page_nr()                                        -> arch/arm/mm.c
>> void put_page()                                           -> arch/arm/mm.c
>> bool get_page_nr()                                        -> arch/arm/mm.c
>> bool get_page()                                           -> arch/arm/mm.c
>> int get_page_type()                                       -> arch/arm/mm.c
>> void put_page_type()                                      -> arch/arm/mm.c
>> int create_grant_host_mapping()                           -> arch/arm/mm.c
>> int replace_grant_host_mapping()                          -> arch/arm/mm.c
>> bool is_iomem_page()                                      -> arch/arm/mm.c
>> void clear_and_clean_page()                               -> arch/arm/mm.c
>> unsigned long get_upper_mfn_bound()                       -> arch/arm/mm.c
>> """
> 
> The placement of all the ones I didn't comment on look fine to me. It would 
> be good to have a second opinion from either Bertrand or Stefano before you 
> start moving the functions.

I agree to all your above comments, and sure I can wait for a few days for other
maintainers opinion before start moving the code.

> 
>>>> diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c
>>>> index e05cca3f86..889ada6b87 100644
>>>> --- a/xen/arch/arm/mmu/setup.c
>>>> +++ b/xen/arch/arm/mmu/setup.c
>>>> @@ -329,6 +329,33 @@ void __init setup_mm(void)
>>>>  }
>>>>  #endif
>>>>  +/*
>>> 
>>> Why did the second '*' disappear?
>> According to the CODING_STYLE, we should use something like this:
>> /*
>>  * Example, multi-line comment block.
>>  *
>>  * Note beginning and end markers on separate lines and leading '*'.
>>  */
>> Instead of "/**” in the beginning. But I think you made a point, I need
>> to mention that I took the opportunity to fix the comment style in commit
>> message.
> 
> We have started to use /** which I think is for Doxygen (see the PDX series). 
> So I think the CODING_STYLE needs to be updated rather than removing the 
> extra *.

Ahhh thanks for the context, I totally forgot the Doxygen…Then I will use
"/**” in v6.

Kind regards,
Henry

> 
> Cheers,
> 
> -- 
> Julien Grall


 


Rackspace

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