Re: [PATCH] xen/efi: Handle efi_memmap with Xen relocating itself

[Jan Beulich <jbeulich@suse.com>]

On 10.11.2026 15:42, Jason Andryuk wrote:
> On 2026-11-10 03:42, Jan Beulich wrote:
>> On 07.11.2026 00:18, Jason Andryuk wrote:
>>> --- a/xen/arch/x86/efi/efi-boot.h
>>> +++ b/xen/arch/x86/efi/efi-boot.h
>>> @@ -224,6 +224,16 @@ static void *__init efi_arch_allocate_mmap_buffer(UINTN map_size)
>>>       return ebmalloc(map_size);
>>>   }
>>>   
>>> +static void *__init efi_arch_mmap_buffer_virt(void *ptr)
>>> +{
>>> +    unsigned long load_base;
>>> +
>>> +    /* RIP-relative address is the current Xen load address. */
>>> +    asm("lea __image_base__(%%rip), %0" : "=r" (load_base));
>>> +
>>> +    return ptr - load_base + XEN_VIRT_START;
>>> +}
>>
>> There's nothing specific to the mmap in this function, hence it's name is
>> a little odd.
> 
> It is paired with efi_arch_allocate_mmap_buffer() above, so I wanted the 
> name to indicate that it is converting mmap_buffer to a virt address. 

Hmm, right. And this is entirely different between x86 and Arm. So common
code wants to call a function of this name, but on x86 this may then want
to be a thin wrapper around ...

> Having said that, I am open to renaming if that is desired. 
> Alternatives could be:
> efi_arch_xen_phys_to_virt()
> or
> efi_arch_image_phys_to_virt()
> or
> efi_arch_xen_image_to_virt()

... a function of any of these names (which in turn would be possible to
use for other purposes). Marek - thoughts?

With this constraint on the x86 side, wouldn't you then better add an
ASSERT()-like construct to the actual translation function?

Jan