> > I recently noticed in UEFI spec v2.7, section 2.3.4, Calling
> > Conventions for X64, that “All selectors set to be flat with virtual =
> > physical address. If the UEFI OS loader or OS used
> > SetVirtualAddressMap() to relocate the runtime services in a virtual
> > address space, then this condition does not have to be met. My
> > understanding of it is as shown below. Please correct me if it’s wrong.
> >
> > 1. It’s not mandatory for the OS to call SetVirtualAddressMap()
> >
> > 2. If it’s not called, the OS can still use EFI Runtime Services in
> > physical mode (i.e. PA == VA).
> >
> >
> >
> > For x86_64, I did a quick test with qemu and OVMF. I have commented
> > out call to SetVirtualAddressMap() from kernel and noticed that
> > everything works fine i.e. efi variables have the normal functionality
> > and I ran LUV (Linux UEFI Validation). Not calling
> > SetVirtualAddressMap() doesn’t break anything because on x86 we have
> > 1:1 mappings. So, could someone please let me know why we might still need
> to call SetVirtualAddressMap()?
> >
>
> You are right, and the same applies to arm64. However, Apple Mac EFI is known
> not to tolerate PA==VA at runtime, and there may be other x86 firmware
> implementations that don't work correctly in this case, since they are only tested
> with MS Windows, which also calls SetVirtualAddressMap().
>
> So the safe option is to still call it.
Thanks for the explanation Ard, it makes sense now :)
Regards,
Sai
��.n��������+%������w��{.n�����{����* jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
