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.10950.1603283393926531778 for ; Wed, 21 Oct 2020 05:29:54 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=GWNimW5r; 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=1603283392; 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=QHDGNPKCV4nkp0L+lCVqVOrlG8Es8CLH5YEhRMZjOZo=; b=GWNimW5r+crrO5c5XJ+QkI4FIgYe4K8zvg0teEZt5SKS9sbiKCNqDqDbn7a9OMbCs3e3I1 Gh0BJ/FXAr4WRJJtMg59d0a+DimL0WvPLKIi9PuC7c1GEg+CB4ZkbtWd6HHJFM9plQ3igb 5jVcFYlj9Jyjh5oAm95abn9OA115K8s= 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-225-VLlXjkz3M9uv4zyGCcHwUQ-1; Wed, 21 Oct 2020 08:29:48 -0400 X-MC-Unique: VLlXjkz3M9uv4zyGCcHwUQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 188688049E5; Wed, 21 Oct 2020 12:29:44 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-111.ams2.redhat.com [10.36.113.111]) by smtp.corp.redhat.com (Postfix) with ESMTP id 008235C1C7; Wed, 21 Oct 2020 12:29:41 +0000 (UTC) Subject: =?UTF-8?B?UmU6IOWbnuWkjTog5Zue5aSNOiBbUEFUQ0ggdjIgMDEvMTFdIE1kZVBrZywgT3ZtZlBrZzogQ2xlYW4gdXAgR0hDQiBmaWVsZCBvZmZzZXRzIGFuZCBzYXZlIGFyZWE=?= To: Tom Lendacky , gaoliming , devel@edk2.groups.io Cc: 'Brijesh Singh' , 'Michael D Kinney' , 'Zhiguang Liu' , 'Jordan Justen' , 'Ard Biesheuvel' References: <523f270e4e6f7a62cdbebc541b442bd766e7ab3a.1602864557.git.thomas.lendacky@amd.com> <000d01d6a5b9$03d14ef0$0b73ecd0$@byosoft.com.cn> <93c3b271-ccdb-6242-ce23-957eb73a66c0@amd.com> <006f01d6a67d$80b77d80$82267880$@byosoft.com.cn> <8734b948-e36c-81f4-43ae-6c63fba1374b@amd.com> From: "Laszlo Ersek" Message-ID: Date: Wed, 21 Oct 2020 14:29:41 +0200 MIME-Version: 1.0 In-Reply-To: <8734b948-e36c-81f4-43ae-6c63fba1374b@amd.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 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: 8bit On 10/20/20 15:10, Tom Lendacky wrote: > On 10/20/20 3:31 AM, Laszlo Ersek wrote: >> On 10/20/20 03:08, gaoliming wrote: >>> Laszlo and Tom: >>> >>>> -----邮件原件----- >>>> 发件人: Laszlo Ersek >>>> 发送时间: 2020年10月20日 4:42 >>>> 收件人: Tom Lendacky ; gaoliming >>>> ; devel@edk2.groups.io >>>> 抄送: 'Brijesh Singh' ; 'Michael D Kinney' >>>> ; 'Zhiguang Liu' ; >>>> 'Jordan Justen' ; 'Ard Biesheuvel' >>>> >>>> 主题: Re: 回复: [PATCH v2 01/11] MdePkg, OvmfPkg: Clean up GHCB field >>>> offsets and save area >>>> >>>> On 10/19/20 14:50, Tom Lendacky wrote: >>>>> On 10/18/20 8:41 PM, gaoliming wrote: >>>> >>>>>> Please separate the patch for the change in OvmfPkg. >>>>>> One commit can't cross the different packages. >>>>>> I understand this is the incompatible change. But, we still need to follow >>>>>> this rule. >>>> >>>> I disagree. >>>> >>>> We should do whatever we can for avoiding cross-package patches, but in >>>> some cases, they are unavoidable. This is one of those cases. >>> >>> I suggest to define enum GHCB_QWORD_OFFSET, then use typedef GHCB_QWORD_OFFSET GHCB_REGISTER; in Ghcb.h >>> The comments can be added here to describe it is for compatibility. The old one is not recommend. >>> >>> Then, the change in MdePkg is compatible. Next patch is to update OvmfPkg VmgExit to consume GHCB_QWORD_OFFSET. >> >> Ah, I totally missed that we could use typedef to bridge the gap. That >> indeed allows us to do the rename in three steps (only for the type >> name, the enum constant identifiers can stay the same). After the >> rename, the enum constant values can be cleaned up in a separate (4th) >> patch. > > It seems like a lot of churn for just renaming. Yes, it is. (I guess it helps downstreams that only want to cherry-pick patches from specific packages.) > If there are no > objections, I'll keep the GHCB_REGISTER name. The important piece is the > change from hardcoding the offset values to using a calculated value. If the GHCB_REGISTER type name works for you, it certainly works for me :) Thanks Laszlo