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.web10.12320.1620402474039062395 for ; Fri, 07 May 2021 08:47:54 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=H+udTnn/; 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=1620402473; 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=XPd0yn4QGCiMAl2gzF7FIJgBTVsTv8tuQPA0VuRSbtk=; b=H+udTnn/e5W0UQjA7e6to4oaJ4Zl1SjRvMRLelgHPpcWXSYpIyFX2KxsqHs6YQ5oqzwKIs SQPl7HJeb+WgTGAo/mErl+hMipcQSYdZxyglRrkf7CON6f1Hr82uLN7NoMT2dq4Sk2RaR6 NEjvpNrG7J+J6D4yUnAPVrHYqXWdLrs= 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-355-6gbkplVJO4KcPIpakkS23g-1; Fri, 07 May 2021 11:47:49 -0400 X-MC-Unique: 6gbkplVJO4KcPIpakkS23g-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B7C8A801817; Fri, 7 May 2021 15:47:47 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-115-75.ams2.redhat.com [10.36.115.75]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9673D5D9CC; Fri, 7 May 2021 15:47:45 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH RFC v2 09/28] OvmfPkg/VmgExitLib: Allow PMBASE register access in Dxe phase To: Brijesh Singh , Tom Lendacky Cc: devel@edk2.groups.io, James Bottomley , Min Xu , Jiewen Yao , Jordan Justen , Ard Biesheuvel , Erdem Aktas References: <20210430115148.22267-1-brijesh.singh@amd.com> <20210430115148.22267-10-brijesh.singh@amd.com> <39e81516-ae93-e737-4203-af10cb07a9f9@redhat.com> From: "Laszlo Ersek" Message-ID: <877f547e-bdaf-1f22-ae80-0285c4b155e6@redhat.com> Date: Fri, 7 May 2021 17:47:44 +0200 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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/07/21 17:19, Brijesh Singh wrote: > > On 5/7/21 10:10 AM, Laszlo Ersek wrote: >> >>> Sounds good. What's your thought if I take out patch 1 - 9 from this RFC >>> series and submit them as non-RFC for the further review and acceptance >>> ? The patch# 1-9 are basically prepatch before we get into SNP specific >>> bits. >> More precisely, that means patches 1-8 (because patch#9 should be >> replaced by the module-scope override, and also moved to just before >> what is currently patch#21). >> >> Other than that, I agree, this is a good idea. I've anyway thought that >> the MdePkg stuff (5 patches) could be / should be merged up-front in >> separation, and then the subsequent 3 patches for OvmfPkg are basically >> refactoring. We can record the resultant commit range (8 commits) in >> TianoCore#3275, and keep the BZ open for the rest of the work. So go >> ahead please. > > Yes, I will keep patch#9 in SNP series. > > FYI, I will add couple of more patches in MdePkg to define the macros > for AP creation and RMPAJUST instruction. Now that GHCB spec is final, > we are working to get the AP creation implemented for the next version. If the spec is final, then extending the MdePkg patches makes sense, yes. Thanks Laszlo