From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mx.groups.io with SMTP id smtpd.web08.1592.1611368698259174193 for ; Fri, 22 Jan 2021 18:24:58 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=iQ8gNiQa; spf=pass (domain: redhat.com, ip: 63.128.21.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611368697; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=haNwaUQeIa3txmMZtCmkTv3b4hiCtu8mxsSh6O2Fa6U=; b=iQ8gNiQa0g7eqofN8meBdok+94Wkaest3XcaY+ZjUR+OVcNO6SF23ed0mJzPnTTGxieFEg JChZ6SIw8DGWiazTI0/qGUhQsTrG/TeaVWIdkSNfPvbOqagQol0hJnBRpbr9t5ch58oINy 7myB6EJ9qCG4xFlfm7G+dZWx9Dxzk+o= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-126-0FcczcTWMfqLuJoXMs79ug-1; Fri, 22 Jan 2021 21:24:53 -0500 X-MC-Unique: 0FcczcTWMfqLuJoXMs79ug-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0C1358049CF; Sat, 23 Jan 2021 02:24:52 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-81.ams2.redhat.com [10.36.113.81]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9F0AF709AD; Sat, 23 Jan 2021 02:24:50 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Use physical address with SEV-ES To: Andrew Fish , edk2-devel-groups-io Cc: Tom Lendacky , Brijesh Singh , Jordan Justen , Ard Biesheuvel References: <8bba19920e58813f32889dec522bbcd8de113219.1611338106.git.thomas.lendacky@amd.com> <8d660790-fafd-c0d5-f1eb-1e02830a7fa9@redhat.com> <732BE659-4DEA-48C2-9AAB-1C4A776A0021@apple.com> From: "Laszlo Ersek" Message-ID: Date: Sat, 23 Jan 2021 03:24:49 +0100 MIME-Version: 1.0 In-Reply-To: <732BE659-4DEA-48C2-9AAB-1C4A776A0021@apple.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 01/23/21 02:29, Andrew Fish wrote: > >> On Jan 22, 2021, at 4:25 PM, Laszlo Ersek 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