[edk2-devel] [PATCH] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Use physical address with SEV-ES
Laszlo Ersek
lersek at redhat.com
Sat Jan 23 02:24:49 UTC 2021
On 01/23/21 02:29, Andrew Fish wrote:
>
>> On Jan 22, 2021, at 4:25 PM, Laszlo Ersek <lersek at redhat.com> wrote:
>>
>> On 01/22/21 23:40, Tom Lendacky wrote:
>>
>>> Can SetVirtualAddressMap() be called more than once?
>>
>> According to the UEFI spec: no, it can't.
>>
>> The call to SetVirtualAddressMap() must be done with the physical
>> mappings. On successful return from this function, the system must
>> then make any future calls with the newly assigned virtual
>> mappings.
>>
>> [...]
>>
>> The SetVirtualAddressMap() and ConvertPointer() services are only
>> callable in physical mode, so they do not need to be converted
>> from physical pointers to virtual pointers.
>>
>> [...]
>>
>> A virtual address map may only be applied one time. Once the
>> runtime system is in virtual mode, calls to this function return
>> EFI_UNSUPPORTED.
>>
>> (I seem to detect a bit of contradiction between quotes #1+#2 and #3
>> -- the first two quotes seem to explain that a second call is
>> expected to be impossible, whereas the third quote explains how a
>> second or later call should behave. But, anyway, the intent is
>> clear.)
>>
>
> Laszlo,
>
> So the answer is no you can't call it more than once. While the text
> is confusing it describes the only possible behavior.
>
> If you look at the EFI_UNSUPPORTED Status Codes Returned: "EFI
> firmware is not at runtime, or the EFI firmware is already in virtual
> address mapped mode." This is what the edk2 implementation does [1].
> And combine that with this text 'Once all events have been notified,
> the EFI firmware reapplies image "fix-up" information to virtually
> relocate all runtime images to their new addresses'. So basically
> that implies that after the 1st call all the Runtime drivers have been
> fixed up to run at their virtual address. So if you called them again
> at their physical mode address they would likely crash.
Yes, exactly; the question is whether it is even possible to make a
second call to SetVirtualAddressMap(), after the first call returns
successfully, without crashing immediately in the call instruction.
Put differently: whether there is any way where SetVirtualAddressMap()
could remain *accessible* for a 2nd call, after the 1st call succeeds.
If there is no such way, then the last quoted paragraph is useless,
because it specifies a situation that can never happen.
Put yet differently:
- SetVirtualAddressMap can only be called in physical mode,
- when SetVirtualAddressMap returns with success, we're in virtual mode,
- so SetVirtualAddressMap must not be called *at all* for a 2nd time,
- so why give details on *how* SetVirtualAddressMap behaves when its
calling contract is violated?
Ultimately, I would replace:
Once the runtime system is in virtual mode, calls to this function
return EFI_UNSUPPORTED.
with:
Once the runtime system is in virtual mode, calls to this function
are impossible to make.
Thanks!
Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#70701): https://edk2.groups.io/g/devel/message/70701
Mute This Topic: https://groups.io/mt/80036772/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-
More information about the edk2-devel-archive
mailing list