From: Andrew Cooper <andrew.cooper3@citrix.com>

Using an interface based on addresses directly, not modules.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
---
 xen/arch/x86/include/asm/setup.h |  1 +
 xen/arch/x86/setup.c             | 19 +++++++++++++------
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h
index d75589178b91..15dcb62cb5ac 100644
--- a/xen/arch/x86/include/asm/setup.h
+++ b/xen/arch/x86/include/asm/setup.h
@@ -34,6 +34,7 @@ void setup_io_bitmap(struct domain *d);
 
 unsigned long initial_images_nrpages(nodeid_t node);
 void discard_initial_images(void);
+void *bootstrap_map_addr(uint64_t start, uint64_t end);
 void *bootstrap_map(const module_t *mod);
 
 int remove_xen_ranges(struct rangeset *r);
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 82a4375683d2..d4f557b4c50d 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -436,24 +436,22 @@ static void __init normalise_cpu_order(void)
  * Ensure a given physical memory range is present in the bootstrap mappings.
  * Use superpage mappings to ensure that pagetable memory needn't be allocated.
  */
-void *__init bootstrap_map(const module_t *mod)
+void *__init bootstrap_map_addr(uint64_t start, uint64_t end)
 {
     static unsigned long __initdata map_cur = BOOTSTRAP_MAP_BASE;
-    uint64_t start, end, mask = (1L << L2_PAGETABLE_SHIFT) - 1;
+    uint64_t mask = (1L << L2_PAGETABLE_SHIFT) - 1;
     void *ret;
 
     if ( system_state != SYS_STATE_early_boot )
-        return mod ? mfn_to_virt(mod->mod_start) : NULL;
+        return end ? maddr_to_virt(start) : NULL;
 
-    if ( !mod )
+    if ( !end )
     {
         destroy_xen_mappings(BOOTSTRAP_MAP_BASE, BOOTSTRAP_MAP_LIMIT);
         map_cur = BOOTSTRAP_MAP_BASE;
         return NULL;
     }
 
-    start = (uint64_t)mod->mod_start << PAGE_SHIFT;
-    end = start + mod->mod_end;
     if ( start >= end )
         return NULL;
 
@@ -469,6 +467,15 @@ void *__init bootstrap_map(const module_t *mod)
     return ret;
 }
 
+void *__init bootstrap_map(const module_t *mod)
+{
+    if ( !mod )
+        return bootstrap_map_addr(0, 0);
+
+    return bootstrap_map_addr(pfn_to_paddr(mod->mod_start),
+                              pfn_to_paddr(mod->mod_start) + mod->mod_end);
+}
+
 static void __init move_memory(
     uint64_t dst, uint64_t src, unsigned int size)
 {
-- 
2.30.2

On 30.08.2024 23:46, Daniel P. Smith wrote:
> From: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> Using an interface based on addresses directly, not modules.
> 
> No functional change.

Okay, a mechanical transformation. But what's the goal?

> --- a/xen/arch/x86/include/asm/setup.h
> +++ b/xen/arch/x86/include/asm/setup.h
> @@ -34,6 +34,7 @@ void setup_io_bitmap(struct domain *d);
>  
>  unsigned long initial_images_nrpages(nodeid_t node);
>  void discard_initial_images(void);
> +void *bootstrap_map_addr(uint64_t start, uint64_t end);

Better paddr_t?

Jan

On 9/4/24 02:49, Jan Beulich wrote:
> On 30.08.2024 23:46, Daniel P. Smith wrote:
>> From: Andrew Cooper <andrew.cooper3@citrix.com>
>>
>> Using an interface based on addresses directly, not modules.
>>
>> No functional change.
> 
> Okay, a mechanical transformation. But what's the goal?

I would defer to Andy's reply.

>> --- a/xen/arch/x86/include/asm/setup.h
>> +++ b/xen/arch/x86/include/asm/setup.h
>> @@ -34,6 +34,7 @@ void setup_io_bitmap(struct domain *d);
>>   
>>   unsigned long initial_images_nrpages(nodeid_t node);
>>   void discard_initial_images(void);
>> +void *bootstrap_map_addr(uint64_t start, uint64_t end);
> 
> Better paddr_t?

I don't see why not. It was Andy's patch, so unless he has an objection, 
I can change it.

v/r,
dps

On 04/09/2024 7:49 am, Jan Beulich wrote:
> On 30.08.2024 23:46, Daniel P. Smith wrote:
>> From: Andrew Cooper <andrew.cooper3@citrix.com>
>>
>> Using an interface based on addresses directly, not modules.
>>
>> No functional change.
> Okay, a mechanical transformation. But what's the goal?

Its used by patch 12 which adds boostrap_map_bm(), but does want to be
reordered later in the series to immediately before it's used.


This is a patch of mine from a prior cleanup attempt.

I'm still itching to get rid of the chunking and backwards memcpy in
move_module(), but I'll pick the work back up again when it won't
collide with this series.

~Andrew

On 9/4/24 06:47, Andrew Cooper wrote:
> On 04/09/2024 7:49 am, Jan Beulich wrote:
>> On 30.08.2024 23:46, Daniel P. Smith wrote:
>>> From: Andrew Cooper <andrew.cooper3@citrix.com>
>>>
>>> Using an interface based on addresses directly, not modules.
>>>
>>> No functional change.
>> Okay, a mechanical transformation. But what's the goal?
> 
> Its used by patch 12 which adds boostrap_map_bm(), but does want to be
> reordered later in the series to immediately before it's used.

I can reorder the series to make these this happen just before patch 12 
and ensure that they aren't introduced until the first usage of 
boostrap_map_bm().

v/r,
dps