From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (NAM10-BN7-obe.outbound.protection.outlook.com [40.92.40.99]) by mx.groups.io with SMTP id smtpd.web11.50013.1600718402684475655 for ; Mon, 21 Sep 2020 13:00:03 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@outlook.com header.s=selector1 header.b=RLgEc44V; spf=pass (domain: outlook.com, ip: 40.92.40.99, mailfrom: michael.kubacki@outlook.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EsnkKKJ19Jp7iI/7pG5gQ9qNfsSn4NMkO0mA2zZsKDEQFK9xhsEmWpawuypvK9QmrGfTVsDNQizpQRTSBpPcr3zZqFn/Z1T2kULzgczKrNMJpfGtTU9bx7e9i7haud68Yz2QNE/4/UFCgYrCsP4x6CUhxwmYJ4BR+KM0n7atnl9zAHklLXDUcuHmFg2w73xXPj1OoOFL0ukr36Qfffw6kkTYtBimT0BwnvwBmKst8JM16qEnbTa5t76Yx4wT6Bih2wk3vcXu/zZ7xn9Xsbwzydexak/8BuNLhdTSZyODvDIXTb80srrNCjW8yzkM0GQuyVCEIEC8W8kZpWNY+QXuNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oTFwVoc/3XcDQkVFK8E180XAhT1y6UAIVwDXhMVc4CQ=; b=Yf76CieDo1mrcuv3pprfSwBc1gAlB9rVYMloq74PSvEi99a1N0pnko3pgwm5rx+MK5bvaSGoTI1gpTlWaNUyCT1zqicVmRVqYQ8p5v0IQO8PrPh4seoJ9ls0ctX+9aGgx7hakS+t8pAk9PWW3WwGS3xyKpN4+gQpomIoPq8Yhk19G914uwUjjQxcCHIhyuRIq406CQekkKVRtBTQWfWh7i6CKAtI2XAjuMlVmJrJYuQvh+FrnvrGs9v9kKgNCT3+osGXeNHnW6ZGLMfl4p9H09ojcSGliiYcNcEIegoXGgS5UKnoL/r4q84mApzZS0JkKpj7XTzFh+NtbPHUt1REAQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oTFwVoc/3XcDQkVFK8E180XAhT1y6UAIVwDXhMVc4CQ=; b=RLgEc44Vj4czRkMWkzcdAbuM952XWpYS8OdI2bTHjrzMP2HebiPHHvPAlS7RF4pfssdIZGIaqMFl8czyPUHJbIsagDtCC2wOKpHY0mf6u4LVguoBF+ZiMs6+K1LAbmjMLxDMHOEQZIQuDoXR9KnvPdrBORas3kvGr56niGw5J5Bumr0RkkbIbtqbB8uFAyDI6Uv1GuCKl6+LmadSxG+Moh/QckmnmmSIrxXA5hvAi2AzUbrkAjRs+LhQGhZ9y2G2d7xTCDMo513iytv/uKWdQP8G9F/w1mUmca2XWerXZmyMdWxKCe32f29prAUE4a3FNvIhmvpZ4TkeJgZymE+ZOg== Received: from BN7NAM10FT047.eop-nam10.prod.protection.outlook.com (2a01:111:e400:7e8f::53) by BN7NAM10HT196.eop-nam10.prod.protection.outlook.com (2a01:111:e400:7e8f::391) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.15; Mon, 21 Sep 2020 20:00:01 +0000 Received: from DM5PR07MB3435.namprd07.prod.outlook.com (2a01:111:e400:7e8f::46) by BN7NAM10FT047.mail.protection.outlook.com (2a01:111:e400:7e8f::126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.15 via Frontend Transport; Mon, 21 Sep 2020 20:00:01 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:99D9546A8FE1A53A68744D16274AA65C93FA0723F65FA6602E065B94EB5112C6;UpperCasedChecksum:5BA4C0E9F6575BB70C9E7181290AA7AC1ED60C6A95A44EC4B783293A4CC854B2;SizeAsReceived:9541;Count:49 Received: from DM5PR07MB3435.namprd07.prod.outlook.com ([fe80::3cf7:b64b:94b:cb64]) by DM5PR07MB3435.namprd07.prod.outlook.com ([fe80::3cf7:b64b:94b:cb64%5]) with mapi id 15.20.3391.026; Mon, 21 Sep 2020 20:00:01 +0000 Subject: Re: [edk2-devel] [PATCH v1 1/1] MdePkg: Correct EFI_BLOCK_IO_PROTOCOL_REVISION3 value To: "Ni, Ray" , "devel@edk2.groups.io" CC: "Kinney, Michael D" , Liming Gao , "Liu, Zhiguang" References: From: "Michael Kubacki" Message-ID: Date: Mon, 21 Sep 2020 13:00:00 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 In-Reply-To: X-ClientProxiedBy: MW2PR16CA0070.namprd16.prod.outlook.com (2603:10b6:907:1::47) To DM5PR07MB3435.namprd07.prod.outlook.com (2603:10b6:4:67::14) Return-Path: michael.kubacki@outlook.com X-Microsoft-Original-Message-ID: <892fc88f-db1f-0080-b40a-2970c34bb4c4@outlook.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [IPv6:2001:4898:d8:39:d14d:6a40:16a:60df] (2001:4898:80e8:a:516c:6a40:16a:60df) by MW2PR16CA0070.namprd16.prod.outlook.com (2603:10b6:907:1::47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.14 via Frontend Transport; Mon, 21 Sep 2020 20:00:00 +0000 X-Microsoft-Original-Message-ID: <892fc88f-db1f-0080-b40a-2970c34bb4c4@outlook.com> X-TMN: [PGuKcu4aK51qUJJd2DOw4uEhgqFQ7tL7kx+H0Gk5Rat73j9zPduKqTKDeAYSJyz2] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 49 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: ec4e47a1-bd77-442e-2244-08d85e68ec1b X-MS-TrafficTypeDiagnostic: BN7NAM10HT196: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: f7EZI4J6aN5YQh4hgPBRjMHnXie8dxn3YVnLZUoSW4NcHJT64oyAM/he8xLTDjzmOPbtUXm/5AlSx2d/YC9avU46/hkuGQP5eq/HxnIX3PtwmxhD78IdS93oO0eF1Q+ZySpSxS/BFhGmSOh5x2/cvVoPjIp8K0EG5J/v0lVwmjqFO72BYVVR8fHR75NXooHvoQNUDEjV5BpEJlfVtOXPdbEB5HwP38me58KxyNS9K1SIU9uHy9mMR23HU5Acu3Bt X-MS-Exchange-AntiSpam-MessageData: zoJTOWxPsVbMa7ulIfEHsNxDxf57yLBZE2UAtqU1WsalcliFECv7FP5mUV57vFqmpM/c7S1C63wGUAfc56zfQsDQYRjWJQTSZDjbgPy0WbdFvGtPYNiOgtoXQzy36ZiVeRgKhaYslUGHylrj0g2lLj35y/kgg+9/Fd581D0q4Fh7eFibLsbetcyTvC/AQZBV12qeDTOyq/yM3BotJ8Rp7g== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ec4e47a1-bd77-442e-2244-08d85e68ec1b X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2020 20:00:01.0852 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: BN7NAM10FT047.eop-nam10.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7NAM10HT196 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable I found the issue while manually reviewing some protocol structures=20 against the UEFI spec. I'm going to leave that question to the MdePkg and UEFI Specification=20 maintainers as changing the specification may have an impact on other=20 implementations that needs to be considered. My only preference on the=20 topic is that the edk2 implementation and UEFI Specification do not=20 conflict. Since the patch to match the value against the spec has been=20 submitted, I'm happy to make any potential modifications based on the=20 decision. Thanks, Michael On 9/20/2020 7:28 PM, Ni, Ray wrote: > Disk Utility code that consumes the REVISION3 macro: > if (BlkIo->Revision >=3D EFI_BLOCK_IO_PROTOCOL_REVISION3 && > BlkIo->Media->OptimalTransferLengthGranularity !=3D 0 > ) { > // > // Compute the least common multiple of OptimalTransferLengthGr= anularity and LogicalBlocksPerPhysicalBlock > // > *OptimalTransferBlocks =3D Lcm ( > BlkIo->Media->OptimalTransferLengthGranularity, > *OptimalTransferBlocks > ); > } >=20 > Even we could release a new version of tool with the correct value, ther= e is no way to inform the > old tool users to do the upgrade. >=20 > What caused the issue to be found? > Would keeping the implementation unchanged but correcting the spec conte= nt be the easier way? >=20 > Thanks, > Ray >=20 >> -----Original Message----- >> From: Michael Kubacki >> Sent: Saturday, September 19, 2020 8:26 AM >> To: Ni, Ray ; devel@edk2.groups.io >> Cc: Kinney, Michael D ; Liming Gao >> ; Liu, Zhiguang >> Subject: Re: [edk2-devel] [PATCH v1 1/1] MdePkg: Correct >> EFI_BLOCK_IO_PROTOCOL_REVISION3 value >> >> What do you propose as an alternative? >> >> Can a new version of the tool be released with the correct value? >> >> Thanks, >> Michael >> >> On 9/18/2020 4:53 PM, Ni, Ray wrote: >>> As far as I know, EFI disk utility consumesthis new field for >>> performance. The utility is in Intel website for external downloads. >>> >>> ----------------------------------------------------------------------= -- >>> *=E5=8F=91=E4=BB=B6=E4=BA=BA:* devel@edk2.groups.io =E4=BB=A3=E8=A1=A8 Michael >>> Kubacki >>> *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* Saturday, September 19, 2020 2= :54:54 AM >>> *=E6=94=B6=E4=BB=B6=E4=BA=BA:* devel@edk2.groups.io ; Ni, Ray >>> >>> *=E6=8A=84=E9=80=81:* Kinney, Michael D ; = Liming Gao >>> ; Liu, Zhiguang >>> *=E4=B8=BB=E9=A2=98:* Re: [edk2-devel] [PATCH v1 1/1] MdePkg: Correct >>> EFI_BLOCK_IO_PROTOCOL_REVISION3 value >>> Hi Ray, >>> >>> Rev3 adds the UINT32 field OptimalTransferLengthGranularity field to >>> EFI_BLOCK_IO_MEDIA. A preexisting binary Block I/O producer that uses >>> this field will set their revision to the higher value and the only >>> check I see in edk2 (PartitionDxe) on the revision to access this fiel= d >>> checks for >=3D EFI_BLOCK_IO_PROTOCOL_REVISION3. >>> >>> If a binary Block I/O producer is built with the new value that is >>> consumed by a module built with the older value it might ignore the >>> OptimalTransferLengthGranularity field. I do not see where this is the >>> case in edk2 other than PartitionDxe which sets the >>> OptimalTransferLengthGranularity field to zero for Rev3. >>> >>> You have contributed to this code in the past so feel free to provide >>> any further insight if needed. >>> >>> That said, this change was made to fix a bug in the edk2 implementatio= n >>> to remove a conflict with the UEFI Spec, the two should be in agreemen= t. >>> >>> I suggest the change be added to the next stable tag release notes so >>> authors of such modules are made aware they should release an update >>> with the new revision value. >>> >>> Thanks, >>> Michael >>> >>> On 9/17/2020 6:25 PM, Ni, Ray wrote: >>>> Mike, >>>> Have you evaluated the impact to the already-released module that rel= ies >> on the macro value? >>>> >>>> Basically, you changed to a smaller value that may cause a revision3 = check >> fail: >>>> a released module expects the revision is bigger than 0x31, but the v= alue is >> 0x1f. >>>> >>>> Thanks, >>>> Ray >>>> >>>>> -----Original Message----- >>>>> From: devel@edk2.groups.io On Behalf Of >> Michael Kubacki >>>>> Sent: Tuesday, September 15, 2020 2:11 AM >>>>> To: devel@edk2.groups.io >>>>> Cc: Kinney, Michael D ; Liming Gao >> ; Liu, Zhiguang >>>>> >>>>> Subject: [edk2-devel] [PATCH v1 1/1] MdePkg: Correct >> EFI_BLOCK_IO_PROTOCOL_REVISION3 value >>>>> >>>>> From: Michael Kubacki >>>>> >>>>> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3D2961 >>>>> >>>>> The value of EFI_BLOCK_IO_PROTOCOL_REVISION3 is currently >>>>> 0x00020031. However, the value assigned in the UEFI Specification >>>>> 2.8B is ((2<<16) | (31)) which is 0x0002001F. >>>>> >>>>> Cc: Michael D Kinney >>>>> Cc: Liming Gao >>>>> Cc: Zhiguang Liu >>>>> Signed-off-by: Michael Kubacki >>>>> --- >>>>> =C2=A0=C2=A0 MdePkg/Include/Protocol/BlockIo.h | 2 +- >>>>> =C2=A0=C2=A0 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/MdePkg/Include/Protocol/BlockIo.h >> b/MdePkg/Include/Protocol/BlockIo.h >>>>> index 7b332691ede3..3bd76885e11c 100644 >>>>> --- a/MdePkg/Include/Protocol/BlockIo.h >>>>> +++ b/MdePkg/Include/Protocol/BlockIo.h >>>>> @@ -201,7 +201,7 @@ typedef struct { >>>>> >>>>> =C2=A0=C2=A0 #define EFI_BLOCK_IO_PROTOCOL_REVISION=C2=A0 0x0001000= 0 >>>>> =C2=A0=C2=A0 #define EFI_BLOCK_IO_PROTOCOL_REVISION2 0x00020001 >>>>> -#define EFI_BLOCK_IO_PROTOCOL_REVISION3 0x00020031 >>>>> +#define EFI_BLOCK_IO_PROTOCOL_REVISION3 0x0002001F >>>>> >>>>> =C2=A0=C2=A0 /// >>>>> =C2=A0=C2=A0 /// Revision defined in EFI1.1. >>>>> -- >>>>> 2.28.0.windows.1 >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>>=20 >>> >>>