From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id AD6B2AC0D64 for ; Wed, 6 Sep 2023 06:33:07 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=PMB9q889ml/rl/SVJvzRLsSm7/XvUeLzvIvHQyR6RCo=; c=relaxed/simple; d=groups.io; h=ARC-Seal:ARC-Message-Signature:ARC-Authentication-Results:From:To:CC:Subject:Thread-Topic:Thread-Index:Date:Message-ID:References:In-Reply-To:Accept-Language:msip_labels:MIME-Version:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type; s=20140610; t=1693981986; v=1; b=jus58ivvprigj6MlVMOk7nYGgZQi3nXDo9YQaPpAT5Ds1+UoLhR77IGlU4DwEi/L4MKPJKtE bYlBLnudPK0Ly0GJUFqt191qKNXPNS+lgt6r7Zpu9ISFNBIlrSLAM6Xahx1JKqw69X17bniU9hL /7GJkxq7e+Nkw1BdubPX6AuU= X-Received: by 127.0.0.2 with SMTP id AF7vYY7687511xQEfpx5nYR1; Tue, 05 Sep 2023 23:33:06 -0700 X-Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by mx.groups.io with SMTP id smtpd.web11.2616.1693981985544449922 for ; Tue, 05 Sep 2023 23:33:05 -0700 X-IronPort-AV: E=McAfee;i="6600,9927,10824"; a="443380665" X-IronPort-AV: E=Sophos;i="6.02,231,1688454000"; d="scan'208,217";a="443380665" X-Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Sep 2023 23:33:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10824"; a="988109859" X-IronPort-AV: E=Sophos;i="6.02,231,1688454000"; d="scan'208,217";a="988109859" X-Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by fmsmga006.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 05 Sep 2023 23:33:04 -0700 X-Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32; Tue, 5 Sep 2023 23:33:03 -0700 X-Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27 via Frontend Transport; Tue, 5 Sep 2023 23:33:03 -0700 X-Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.175) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.27; Tue, 5 Sep 2023 23:33:02 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WsOC9htPWYjsZAf+bifDY3AQZALqMnowHVxnVceEHoR16ufwJmgWdeT+QKrjdt+Zt/x+3+6WrtD8y4+7dRG+AAZAw0wK9RaWrH99QBpD74T2VVnb2C6u5XoGMydrVInrL8xK1d8Q8KrgMP8m8SFEBooKL2GPAqBKBFds5eXZO/9a1sJdz2F9uWz4IBpdhgrATy4pJa4M0QcBpPiN8yq9mxnUnZksABhTFXF853YXy0WWSBb/A+5P0c5z1aPmJACdydgee3goKzVVXv4u+3tmLr6z7cyIhAiYneRB4nzw/hobomOYicmqZyM2DcMtsUfktxOkBxriCxWTqaf6ZMWT5w== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hJdWqxyuFW70rFkXLYiWIFZCwE7F639VL/PKbfFYDOY=; b=YO0ANexmhgE1kp5X+8b9KRe+2iNmfiVqJI9JiFME8EO1J6+Cncbf5JwJTzEpM4B8n0RUu+BXbmqc6005oGU2OB/kbbChC5y+UW3t4YUlzdSGYeo9KH/NNwLj0Fhmtwfw8TBix5y2hHSMKgwpqBO1AX+UMuCvIHHsFLaIEDCUD+pVvo3kKgYL0MDGrwQqBCfYg4U7PgCBEr1ZA2+6Eq+TWPmKADKC7yRdKvxSTJXaxwp4Mka+xPmh886wG/yeg71IV9nXvC7XFJke3rQ0VVQujcwQYZ5cBCrrgtbj7jwhudFroXETxsF3WCdpBumlILWr8WC/NmjuuXr1T/eVjXxhTA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none X-Received: from MN6PR11MB8244.namprd11.prod.outlook.com (2603:10b6:208:470::14) by IA1PR11MB6323.namprd11.prod.outlook.com (2603:10b6:208:389::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6745.33; Wed, 6 Sep 2023 06:33:01 +0000 X-Received: from MN6PR11MB8244.namprd11.prod.outlook.com ([fe80::bf9a:54ca:d270:59b]) by MN6PR11MB8244.namprd11.prod.outlook.com ([fe80::bf9a:54ca:d270:59b%5]) with mapi id 15.20.6745.030; Wed, 6 Sep 2023 06:33:00 +0000 From: "Ni, Ray" To: Nhi Pham , "devel@edk2.groups.io" , "nhi@os.amperecomputing.com" , Ard Biesheuvel , "osde@linux.microsoft.com" CC: "huangming@linux.alibaba.com" , Sami Mujawar , Ard Biesheuvel , "Yao, Jiewen" , Supreeth Venkatesh , "ming.huang-@outlook.com" Subject: Re: [edk2-devel] [PATCH v1 2/2] StandaloneMmPkg: Fix HOB space and heap space conflicted issue Thread-Topic: [edk2-devel] [PATCH v1 2/2] StandaloneMmPkg: Fix HOB space and heap space conflicted issue Thread-Index: AQHZ0CNCYEABNE6yOU+COXoCgetNCLAC5laAgAFBX4CAAmHogIAFFUOAgAFBDoCAAJcYtA== Date: Wed, 6 Sep 2023 06:33:00 +0000 Message-ID: References: <20220209122558.60329-1-huangming@linux.alibaba.com> <20220209122558.60329-3-huangming@linux.alibaba.com> <14f25a95-7153-4eec-8804-a3da768ccb11@linux.alibaba.com> <0e0bc14c-88a1-21a8-0be7-34ed023e1127@amperemail.onmicrosoft.com> <59c604a4-7e65-4319-8441-806a29327f6f@linux.microsoft.com> In-Reply-To: <59c604a4-7e65-4319-8441-806a29327f6f@linux.microsoft.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: MN6PR11MB8244:EE_|IA1PR11MB6323:EE_ x-ms-office365-filtering-correlation-id: 6e4d2197-0026-4694-ebb7-08dbaea31dc7 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam-message-info: GFACZZkcc9lBWAmCei2ddnUfs1Iens3YFozA/c7504qTbRHbsWHAjZxFyqSRdtclXTmA1197KhGJjBAvHg6q44Uh9d8owVwZZLe2IJWb4oKPpPO4ZdoDu4UxTYkzgoWP349vK4VQA5+LecFTsSSyszsv7O4e2DPEzr0mfshBiGswb7YzJpa/bE7h5MX+e8SaJnaAUBdyoRv1Q3ENFDw5ITNRPsarkFFrp+B8LDFxG4TxqQ7TLpPX6TuGTsXFlNywK6fCXawzle/QYgcKEdqJxwJeb8kdQGn7bf2K1LBuEgHJV4p/QPApciDBNg3T/A3DtL6XxSVOPLynXQWjnKjcfbLqo9tmvWcU2DaEeheI30zBF93mRbpqa/GYHVEUsB5wSAIh1nni2iy0cD4yqMCcbdwrwMTMzj/Rw0MVfLKmiI7HK4JNjFKh7VnqekdtISm1BWm8ObDiD7N8jR5T5BcrCCRjp3ROvnEcn2NTzmg+/3RcI07/Tr2JiaXnImOJBqig2/8gQegJSXyFNt802EcIpcvL7pdY4PFx1sDSvDRC61oABhkAPe/SDhEFJ3OLVsjWOfVLNGuXcCqiNgK1fxp7GWdZ3vDOm39folkACtnK1lPiCaavlalCZjCiy2F21Tee4yNQNObiab1uOpmKwfrluQ== x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?PY1b1yg1icZhRdR964VqanYDpsx0+C2dhOwpgrDtfhx+2gEIkWKAHiHL04o4?= =?us-ascii?Q?BwuTWrCv0dFFRrFccuUIud/ppEma/SpD1KqlFVb9wtU4+pAAG+GxDhaewzuq?= =?us-ascii?Q?2Sz8E140Ohq/Eqx1aknJaK5lhyt/vUkbN06REiIk+ry+vVR71mYrvWdj6ZMJ?= =?us-ascii?Q?6Ejwk47IFeaQkPjbhu8lPhudZGD8MCu+LLQAoKc2oAvTWcU2pINXYO/hcNPm?= =?us-ascii?Q?qUl3kEYeX73euKT4oo91mwcfbOaviokyjwdeDQ94th4Pz9fIuOQK+qo56CO2?= =?us-ascii?Q?RBE5AeM6t9OKYGHRLQ7OAKKBztSsUNKGhUXb2VXndW6xwNIBFfpEKpNcspeh?= =?us-ascii?Q?NgC3d81hLbkLV/QABNEpcLCI0DwBWalrcKotX6xU/u+01L5tUs0mGN+aYTKx?= =?us-ascii?Q?YYefRexodftbmF3u07qqtTsD86y7x2JTjjOAtu1IChWSnb2FSrGf4s/3oMu7?= =?us-ascii?Q?miAZAdjIs+XLzpqv7dtrN7emFS6Xk3QpXdUW0J6WLBVp3tXu/C8Cs+RLhE6F?= =?us-ascii?Q?aRv3vGSdZUIP6GFvUwX/O7u7rZS/lHSJXVFvijW+iBCq6HFuCawuiW76s9D5?= =?us-ascii?Q?I9uvVYjE1IN+Vf1L0L/nKlWddPzvYxgs6ieBN8kT8B/Md7AhF9J8CGNCqVIW?= =?us-ascii?Q?DLLZdjKrr/xEPpgKK9nOYIJ6QMOvUnFbEn/Z/m4HR5WwObCmNWOlb4VyWtAf?= =?us-ascii?Q?SWH2WosWGJ6caYaXowQPx6WVpWMPoTlU5/Z0SzqE467u14sph7EpHhKmj61j?= =?us-ascii?Q?yCSqSP1+8cS3pbE4d6uEsNWZi5pXHvVXhDbx2goSi8k/IsX0M4u6l7tvd/tC?= =?us-ascii?Q?EBpX/6f1KJmQ7/OBflKTpCKnXuIgqhb3bux+7WPiwcJRX2LLqAeG3IqkMaUK?= =?us-ascii?Q?KviHdAbgbHeAO9wNxl/RykvxKrKGCQr3OvVuw0XiEM6/KXjUT8vHscC7Je2i?= =?us-ascii?Q?QJLf5f5usn1IwfswAL60EbK2pVay8bVZ2rDjAwACfMfpM7N+cZl4Z1ZITvNo?= =?us-ascii?Q?hOSSnYrqkcxQxZRr+1DasEfKfiYlifUVwP8tkdPPh9tcYLCWCtllUXx+HzO8?= =?us-ascii?Q?+OUR7P9AQYD8ztD1qa6mYG9V6yzLE3DabsiUo+3zNkW5W7smnKL1kRgBJL7e?= =?us-ascii?Q?Gjl9E9C1953iaTESvpBrDuUyRuaCi/Jp5eyKHn62NV0awyi3G0YWo742kact?= =?us-ascii?Q?8Jaz9Q+BQqC1+9tVmrxvXADd1Y7tdKNyQC6PfaQlEOIonV+7lVd5rqpc3HBu?= =?us-ascii?Q?GRGCS0DQNObxXhU2A/zUeiqBxbmxXZkkWjj/af3JwVIt/av573qGFduzi8/Y?= =?us-ascii?Q?eh26E1fZrfEYri12LkM/JJ2fVAd9gyPxd+17Ii3cdknT0W7fZRozL2BOmtoc?= =?us-ascii?Q?5yZ2nL6brLlixDlfNMuBWLXMvOTM1C0Km5OG3mvdWh3qA0OxMujlgoBxc5Wj?= =?us-ascii?Q?Ob3Y5sk3GvwEBxae75JjD9jOJ13XOAGhiBdpi/AoMvbU1q60p6oIQGwLZlhz?= =?us-ascii?Q?5pLI9YPQwfKdwA+JLPkxKWoFBIQ6YjFsNLrcTFnF5VDMSSxx2233azNwBWPH?= =?us-ascii?Q?hHrFhrPEn2slQl4H+A8=3D?= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN6PR11MB8244.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6e4d2197-0026-4694-ebb7-08dbaea31dc7 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2023 06:33:00.5474 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: QCC/mEpNeOaGlwBWf9mh/rrb0yXOO5PhFu3VExBh4zX6Lb9tSq9gk0Yx84kNKn13LH/vdj+RLyVaSS/exUkdpg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR11MB6323 X-OriginatorOrg: intel.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,ray.ni@intel.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: R63UBHcg3I5CVc58EPV2tFg6x7686176AA= Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_MN6PR11MB82448EDBAF6AEF4E4D1288D78CEFAMN6PR11MB8244namp_" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=jus58ivv; arc=reject ("signature check failed: fail, {[1] = sig:microsoft.com:reject}"); dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=intel.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io --_000_MN6PR11MB82448EDBAF6AEF4E4D1288D78CEFAMN6PR11MB8244namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am a bit confused. The HOB list in standalone MM is read-only. Why could any module call Build= GuidHob() to modify the HOB. I saw Oliver mentioned something about StMM. I don't know what that is. But= it seems that's ARM specific. Then, I don't think it's proper to modify co= de here for a specific arch ARM. Thanks, Ray ________________________________ From: devel@edk2.groups.io on behalf of Oliver Smith= -Denny Sent: Wednesday, September 6, 2023 5:29 AM To: Nhi Pham ; devel@edk2.groups.io ; nhi@os.amperecomputing.com ; A= rd Biesheuvel Cc: huangming@linux.alibaba.com ; Sami Mujawar= ; Ard Biesheuvel ; Yao, J= iewen ; Supreeth Venkatesh ; ming.huang-@outlook.com Subject: Re: [edk2-devel] [PATCH v1 2/2] StandaloneMmPkg: Fix HOB space and= heap space conflicted issue On 9/4/2023 7:20 PM, Nhi Pham wrote: > On 9/2/2023 3:43 AM, Oliver Smith-Denny wrote: >> On 8/31/2023 1:20 AM, Nhi Pham via groups.io wrote: >> >> If I am understanding this correctly, this is only an issue when >> HOBs are created in StMM, i.e. not from HOBs that are passed in. Is this >> correct? > Yes, the issue only occurs when HOB are created in StandaloneMM by the > HOB library instance > StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.inf >> >> If so, is HOB creation in StMM and supported use case? The only instance > I think it is intended to work as the CreateHob() function is implemented= . Well, that may just be a copy/paste sort of thing :). >> a quick search turns up is the ARM StMM Core entry, where some >> information from TF-A is converted to HOB format. Do we have any other >> use cases (and curious more on this use case). My thought process would >> be that StMM would not create any HOBs. Depending on FW configuration, >> it may receive HOBs from PEI. > > I have a use case when enabling the UEFI Variable driver running in > StandaloneMM. Instead of using the PCDs, the in-memory NVRAM region is > allocated **dynamically** at boot time in the StMM secure memory. Then, > they will be passed into the gVariableFlashInfoHobGuid for being > consumed by other variable MM drivers. > I do believe that per the PI spec, we should have HOB producer and HOB consumer phases, where in this case PEI (if it was the launching entity for StMM) is the HOB producer and StMM is the HOB producer. This is the same pattern the PI spec details for PEI and DXE, where DXE is not intended to create new HOBs, but just to consume information from the previous phase. As I mentioned, there are other interfaces for passing information within a phase, such as protocols, dynamic PCDs, variables, etc. that are built for this application. I think it is useful to adhere to the model for HOBs (which are hand off blocks, one phase handing information to another phase) and that we will create more issues if we rely on HOB consumer phases producing HOBs. My proposal would be to remove the HOB creation code from StMM completely. I believe in your use case that you are describing a dynamic PCD or a protocol could work to pass the information. If we are saying that prior to your patch that HOB creation in StMM was completely broken, anyway, it seems that folks were not relying on this code? Thanks, Oliver -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#108306): https://edk2.groups.io/g/devel/message/108306 Mute This Topic: https://groups.io/mt/89020085/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/19134562= 12/xyzzy [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- --_000_MN6PR11MB82448EDBAF6AEF4E4D1288D78CEFAMN6PR11MB8244namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I am a bit confused.

The HOB list in standalone MM is read-only. Why could any module call Build= GuidHob() to modify the HOB.

I saw Oliver mentioned something about StMM. I don't know what that is= . But it seems that's ARM specific. Then, I don't think it's proper to modi= fy code here for a specific arch ARM.

Thanks,
Ray
From: devel@edk2.groups.io = <devel@edk2.groups.io> on behalf of Oliver Smith-Denny <osde@linux= .microsoft.com>
Sent: Wednesday, September 6, 2023 5:29 AM
To: Nhi Pham <nhi@amperemail.onmicrosoft.com>; devel@edk2.grou= ps.io <devel@edk2.groups.io>; nhi@os.amperecomputing.com <nhi@os.a= mperecomputing.com>; Ard Biesheuvel <ardb@kernel.org>
Cc: huangming@linux.alibaba.com <huangming@linux.alibaba.com>;= Sami Mujawar <sami.mujawar@arm.com>; Ard Biesheuvel <ardb+tianoco= re@kernel.org>; Yao, Jiewen <jiewen.yao@intel.com>; Supreeth Venka= tesh <supreeth.venkatesh@arm.com>; ming.huang-@outlook.com <ming.huang-@outlook.com>
Subject: Re: [edk2-devel] [PATCH v1 2/2] StandaloneMmPkg: Fix HOB sp= ace and heap space conflicted issue
 
On 9/4/2023 7:20 PM, Nhi Pham wrote:
> On 9/2/2023 3:43 AM, Oliver Smith-Denny wrote:
>> On 8/31/2023 1:20 AM, Nhi Pham via groups.io wrote:
>>
>> If I am understanding this correctly, this is only an issue when >> HOBs are created in StMM, i.e. not from HOBs that are passed in. I= s this
>> correct?
> Yes, the issue only occurs when HOB are created in StandaloneMM by the=
> HOB library instance
> StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.inf
>>
>> If so, is HOB creation in StMM and supported use case? The only in= stance
> I think it is intended to work as the CreateHob() function is implemen= ted.

Well, that may just be a copy/paste sort of thing :).

>> a quick search turns up is the ARM StMM Core entry, where some
>> information from TF-A is converted to HOB format. Do we have any o= ther
>> use cases (and curious more on this use case). My thought process = would
>> be that StMM would not create any HOBs. Depending on FW configurat= ion,
>> it may receive HOBs from PEI.
>
> I have a use case when enabling the UEFI Variable driver running in > StandaloneMM. Instead of using the PCDs, the in-memory NVRAM region is=
> allocated **dynamically** at boot time in the StMM secure memory. Then= ,
> they will be passed into the gVariableFlashInfoHobGuid for being
> consumed by other variable MM drivers.
>

I do believe that per the PI spec, we should have HOB producer and HOB
consumer phases, where in this case PEI (if it was the launching entity
for StMM) is the HOB producer and StMM is the HOB producer. This is the
same pattern the PI spec details for PEI and DXE, where DXE is not
intended to create new HOBs, but just to consume information from the
previous phase.

As I mentioned, there are other interfaces for passing information
within a phase, such as protocols, dynamic PCDs, variables, etc. that
are built for this application. I think it is useful to adhere to the
model for HOBs (which are hand off blocks, one phase handing information to another phase) and that we will create more issues if we rely on
HOB consumer phases producing HOBs.

My proposal would be to remove the HOB creation code from StMM
completely. I believe in your use case that you are describing a dynamic PCD or a protocol could work to pass the information.

If we are saying that prior to your patch that HOB creation in StMM was
completely broken, anyway, it seems that folks were not relying on this
code?

Thanks,
Oliver





_._,_._,_
Groups.io Links:

=20 You receive all messages sent to this group. =20 =20

View/Reply Online (#108306) | =20 | Mute = This Topic | New Topic
Your Subscriptio= n | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_
--_000_MN6PR11MB82448EDBAF6AEF4E4D1288D78CEFAMN6PR11MB8244namp_--