RE: Query regarding SetVirtualAddressMap()
> > AFAIK, ExitBootServices() means that boot services are no longer
> > needed by OS/bootloader and hence firmware can terminate them. Does it
> > also mean that the system is in runtime mode..? (I don't think so, as, I
> > didn't
> find it in UEFI spec).
> >
>
> Yes
>
> > Also, could you please enlighten me on, Why calling
> > SetVirtualAddressMap() is optional, why not make it mandatory?
> >
>
> Because it depends on the OS whether it needs it or not. Also, there will
> always
> be a window after calling EBS() and before calling SVAM() where we are at
> runtime and no virtual mapping is installed yet, so mandating SVAM() is a bit
> ambiguous anyway.
Thanks for clarifying my doubts :)
Regards,
Sai
N�r��yb�X��ǧv�^�){.n�+{�y^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
Re: Query regarding SetVirtualAddressMap()
On 18 May 2018 at 02:50, Prakhya, Sai Praneeth wrote: > + Ricardo > >> > > 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, > > Some doubts again, > When SetVirtualAddressMap() isn't called, how does Apple Mac EFI realize that > the system is in runtime mode and how does it realize that it should now start > using VA instead of PA? > > Extending it further, if SetVirtualAddressMap() isn't called, any platform > firmware > shouldn't be aware that the system is in runtime mode.. right? > > Or does the firmware behavior change on call to ExitBootServices()? > Yes. > AFAIK, ExitBootServices() means that boot services are no longer needed by > OS/bootloader and hence firmware can terminate them. Does it also mean that > the system is in runtime mode..? (I don't think so, as, I didn't find it in > UEFI spec). > Yes > Also, could you please enlighten me on, > Why calling SetVirtualAddressMap() is optional, why not make it mandatory? > Because it depends on the OS whether it needs it or not. Also, there will always be a window after calling EBS() and before calling SVAM() where we are at runtime and no virtual mapping is installed yet, so mandating SVAM() is a bit ambiguous anyway. >> > 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(). > > Regards, > Sai -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Query regarding SetVirtualAddressMap()
+ Ricardo
> > > 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,
Some doubts again,
When SetVirtualAddressMap() isn't called, how does Apple Mac EFI realize that
the system is in runtime mode and how does it realize that it should now start
using VA instead of PA?
Extending it further, if SetVirtualAddressMap() isn't called, any platform
firmware
shouldn't be aware that the system is in runtime mode.. right?
Or does the firmware behavior change on call to ExitBootServices()?
AFAIK, ExitBootServices() means that boot services are no longer needed by
OS/bootloader and hence firmware can terminate them. Does it also mean that
the system is in runtime mode..? (I don't think so, as, I didn't find it in
UEFI spec).
Also, could you please enlighten me on,
Why calling SetVirtualAddressMap() is optional, why not make it mandatory?
> > 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().
Regards,
Sai
N�r��yb�X��ǧv�^�){.n�+{�y^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
RE: Query regarding SetVirtualAddressMap()
> > 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
Re: Query regarding SetVirtualAddressMap()
On 15 May 2018 at 09:07, Prakhya, Sai Praneeth wrote: > Hi All, > > > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
