From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Wed, 17 Jul 2019 06:15:28 -0700 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 mx1.redhat.com (Postfix) with ESMTPS id BC7243D37; Wed, 17 Jul 2019 13:15:27 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-5.ams2.redhat.com [10.36.117.5]) by smtp.corp.redhat.com (Postfix) with ESMTP id 387EE5D9CC; Wed, 17 Jul 2019 13:15:25 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH 0/3] MdePkg/MdeModulePkg: Introduce a pcd to control runtime services To: devel@edk2.groups.io, zhichao.gao@intel.com Cc: Michael D Kinney , Liming Gao , Jian J Wang , Hao A Wu , Ray Ni , Star Zeng , Sean Brogan , Michael Turner , Bret Barkelew References: <20190717073725.30304-1-zhichao.gao@intel.com> From: "Laszlo Ersek" Message-ID: Date: Wed, 17 Jul 2019 15:15:24 +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: <20190717073725.30304-1-zhichao.gao@intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 17 Jul 2019 13:15:27 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Hello Zhichao, On 07/17/19 09:37, Gao, Zhichao wrote: > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1907 > > UEFI spec 2.8 introduce a new variable L"RuntimeServicesSupported". > If some runtime sevices is not supported at runtime phase, the variable > should present at boot services. It is a bitmask value, the bit value of > zero indicate the related runtime services is not supported at runtime > phase. > Add the difinition and use it to control Capsule runtime services. > > Cc: Michael D Kinney > Cc: Liming Gao > Cc: Jian J Wang > Cc: Hao A Wu > Cc: Ray Ni > Cc: Star Zeng > Cc: Sean Brogan > Cc: Michael Turner > Cc: Bret Barkelew > > Zhichao Gao (3): > MdePkg/UefiSpec.h: Add define of runtime services support > MdePkg: Indicate new pcd PcdRuntimeServicesSupport > MdeModulePkg/CapsuleRuntimeDxe: Control runtime services supported Is a given platform expected to set the new PCD in accordance with other platform settings? Here's why I'm asking. OVMF does not support capsule services, as shown by the following library class resolution in the OVMF DSC files: CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf OVMF will return EFI_UNSUPPORTED when the capsule runtime services are invoked. I'm not sure if the new PCD (and new UEFI variable, "RuntimeServicesSupported") place new requirements on OVMF. It looks like they do. (1) If you agree, can you please include a new patch for OvmfPkg that clears the EFI_RT_SUPPORTED_UPDATE_CAPSULE and RT_SUPPORTED_QUERY_CAPSULE_CAPABILITIES bits in the PCD, in all three DSC files? (2) And, the same applies to all three ArmVirtPkg platforms: ArmVirtQemu, ArmVirtQemuKernel, and ArmVirtXen. (3) Furthermore, we already seem to have a related (generic) PCD, namely PcdCapsuleInRamSupport. If that PCD is set to FALSE, then UpdateCapsule() in "MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleService.c" will return EFI_UNSUPPORTED. Should we introduce a consistency check somewhere, between the capsule-related bits of the PcdRuntimeServicesSupport bitmask, and PcdCapsuleInRamSupport? I'm getting confused by the possible interactions between: - PcdRuntimeServicesSupport - PcdCapsuleInRamSupport - and the CapsuleLib class resolution. Thanks! Laszlo