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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 10.11.2026 16:14, Jan Beulich wrote:
> 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?

Or use the existing (and Arm) logic when the pointer isn't within the Xen
image. (There can be ambiguous cases, though, I fear.)

Jan