From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web11.8315.1621409268062624999 for ; Wed, 19 May 2021 00:27:48 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=TAlfGIFo; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1621409267; 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=uuSsIW6zyaagCSSKNxMTRzydAHEG4N+lZ6y6/Hb/hoU=; b=TAlfGIFoatPETYruLl/Q06hEQAilwh2y9Ssl0DqmQo0eLEzQojwOfM8v7v0rsk8L8PQPTl uFYng5teSQ+YvqBFCzCELQhL8/IK1jNt4xVqD5oZrxottiMWClX7s8ADMAwppu3SmK3yUZ jxCWvHhrivKk5tNnwr75rojiXsKmyk0= 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-121-2bJDL6IVMVONmcDKi3AGIw-1; Wed, 19 May 2021 03:27:43 -0400 X-MC-Unique: 2bJDL6IVMVONmcDKi3AGIw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 52DC91005D47; Wed, 19 May 2021 07:27:42 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-238.ams2.redhat.com [10.36.112.238]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C32845D762; Wed, 19 May 2021 07:27:40 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v2] UefiCpuPkg/MpInitLib: Allocate a separate SEV-ES AP reset stack area To: devel@edk2.groups.io, thomas.lendacky@amd.com Cc: Brijesh Singh , Eric Dong , Ray Ni , Rahul Kumar , =?UTF-8?Q?Marvin_H=c3=a4user?= References: <3cae2ac836884b131725866264e0a0e1897052de.1621024125.git.thomas.lendacky@amd.com> <5394e010-6088-18e8-9a90-65eb55bbfac2@redhat.com> <7d3d835a-4354-108d-17b7-8679eb8c67d1@amd.com> From: "Laszlo Ersek" Message-ID: <991462a7-042c-3186-0459-84c75de245b9@redhat.com> Date: Wed, 19 May 2021 09:27:39 +0200 MIME-Version: 1.0 In-Reply-To: <7d3d835a-4354-108d-17b7-8679eb8c67d1@amd.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 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 05/17/21 17:03, Lendacky, Thomas wrote: > On 5/16/21 11:22 PM, Laszlo Ersek wrote: >> But now, with SEV-ES enabled, we'll have a separate, discontiguous area >> -- and neither BackupAndPrepareWakeupBuffer(), nor its counterpart >> RestoreWakeupBuffer() take that into account. >> >> Therefore I think, while this patch is regression-free for the SEV-ES >> *disabled* case, it may corrupt memory (through not restoring the AP >> stack area's original contents) with SEV-ES enabled. > > This is the current behavior for SEV-ES. The wakeup buffer memory is > marked as reserved, at least in the DXE phase. Another question that occurred to me later: where does this reservation happen? If we have a separate allocation for the AP stacks now, do we need to reserve that too, separately? What about PEI in general? Why is there no risk of corruption there? (Sorry if these are lame questions!) Thanks, Laszlo