Re: [edk2-devel] [PATCH] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Use physical address with SEV-ES

["Laszlo Ersek" <lersek@redhat.com>]

On 01/23/21 02:29, Andrew Fish wrote:
>
>> On Jan 22, 2021, at 4:25 PM, Laszlo Ersek <lersek@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