From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.61]) by mx.groups.io with SMTP id smtpd.web10.1112.1588273103583225453 for ; Thu, 30 Apr 2020 11:58:24 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Rks8mWrc; spf=pass (domain: redhat.com, ip: 205.139.110.61, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588273102; 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=tguRyhzMY1tnW7Z7CtRdGRe9RLIlip8UhZ2D3WncHh8=; b=Rks8mWrcQd1wRqupdYeX9HrEe91Bv/0aJ+INQPrtEliev6QNRr0yof/Qqxb/MuA3t+XFZs dQGfKcg8r0psLAPcXoASOJbt+wR/Xv9AqVXOrudCkne+3msAx2cNviUZR6HyTgtDIIdegd goMLYOBlSAG9+enq1YC0SwczQko4Wfw= 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-24-lpRaQNGKPlu-us5rAMrM9w-1; Thu, 30 Apr 2020 14:58:14 -0400 X-MC-Unique: lpRaQNGKPlu-us5rAMrM9w-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9069880B70B; Thu, 30 Apr 2020 18:58:12 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-115-57.ams2.redhat.com [10.36.115.57]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5AC821C953; Thu, 30 Apr 2020 18:58:10 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v7 33/43] OvmfPkg: Reserve a page in memory for the SEV-ES usage To: devel@edk2.groups.io, thomas.lendacky@amd.com Cc: Jordan Justen , Ard Biesheuvel , Michael D Kinney , Liming Gao , Eric Dong , Ray Ni , Brijesh Singh References: <458aea8874eaecec248c69a3ef809392226ad4e4.1587577317.git.thomas.lendacky@amd.com> From: "Laszlo Ersek" Message-ID: <93f7386f-6e9e-52e1-4a81-d8b599687677@redhat.com> Date: Thu, 30 Apr 2020 20:58:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <458aea8874eaecec248c69a3ef809392226ad4e4.1587577317.git.thomas.lendacky@amd.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Hi Tom, On 04/22/20 19:41, Lendacky, Thomas wrote: > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 > > Reserve a fixed area of memory for SEV-ES use and set a fixed PCD, > PcdSevEsWorkAreaBase, to this value. > > This area will be used by SEV-ES support for two purposes: > 1. Communicating the SEV-ES status during BSP boot to SEC: > Using a byte of memory from the page, the BSP reset vector code can > communicate the SEV-ES status to SEC for use before exception > handling can be enabled in SEC. After SEC, this field is no longer > valid and the standard way of determine if SEV-ES is active should > be used. > > 2. Establishing an area of memory for AP boot support: > A hypervisor is not allowed to update an SEV-ES guest's register > state, so when booting an SEV-ES guest AP, the hypervisor is not > allowed to set the RIP to the guest requested value. Instead an > SEV-ES AP must be re-directed from within the guest to the actual > requested staring location as specified in the INIT-SIPI-SIPI > sequence. > > Use this memory for reset vector code that can be programmed to have > the AP jump to the desired RIP location after starting the AP. This > is required for only the very first AP reset. > > Cc: Jordan Justen > Cc: Laszlo Ersek > Cc: Ard Biesheuvel > Reviewed-by: Laszlo Ersek > Signed-off-by: Tom Lendacky > --- > OvmfPkg/OvmfPkgX64.fdf | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf > index 36414c1f8b49..a0bea86f9875 100644 > --- a/OvmfPkg/OvmfPkgX64.fdf > +++ b/OvmfPkg/OvmfPkgX64.fdf > @@ -82,6 +82,9 @@ [FD.MEMFD] > 0x009000|0x002000 > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize > > +0x00B000|0x001000 > +gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase|gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize > + > 0x010000|0x010000 > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize > > in patch #28 ("OvmfPkg: Create a GHCB page for use during Sec phase"), we carve out two ranges in FD.MEMFD, and introduce a matching set of 4 PCDs. Then in patch #29 ("OvmfPkg/PlatformPei: Reserve GHCB-related areas if S3 is supported"), we reserve those ranges from the OS, as AcpiNVS, if S3 is supported. The reason we only reserve those ranges if S3 is enabled because the ranges are only needed in SEC. (See the details in the commit mesage of patch #29.) In this patch (patch #33), we carve out a third region in FD.MEMFD. We don't seem to ever reserve it. I think that's minimally a problem for S3; the same argument should apply as to the other two areas. Do you agree? Furthermore, I wonder if we should reserve this "work area" from the OS, and even from the DXE phase (!), *regardless* of S3. I can't immediately tell when it's the last time (with S3 disabled) when this area is used. As I understand it, it is only used the first time the APs are booted up. And that should happen still in the PEI phase, because CpuMpPei boots up all the APs and counts them. Afterwards (still in the PEI phase), the APs should be sleeping in ApWakeupFunction(), namely in the code added by patch #40 ("UefiCpuPkg: Allow AP booting under SEV-ES"). If the AP is woken again, it is actually only "released" by the hypervisor, and it goes through the special 64bit->16bit transition, again implemented in patch#40. So ultimately it shouldn't be necessary to reserve this third region (at PcdSevEsWorkAreaBase), if S3 is disabled, because it is never used past the very first AP boot (which happens when CpuMpPei counts the APs). Do I understand right? Thanks! Laszlo