From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail05.groups.io (mail05.groups.io [45.79.224.7]) by spool.mail.gandi.net (Postfix) with ESMTPS id 18E5B740041 for ; Wed, 22 May 2024 15:03:39 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=bqcRwm8mOcob9N/J/XiltWmRwdmAM2phOqzH/rJYQMA=; c=relaxed/simple; d=groups.io; h=DKIM-Filter:Message-ID:Date:MIME-Version:User-Agent:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Resent-Date:Resent-From:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20240206; t=1716390218; v=1; b=fjI3rgshsViV+NxV292uGw47f2ceAjc7auDmmCrEUoHI6+1Rnkj8xP/ycfzyhzx2qTjbhbw5 dna01Z5SK9kOqWQyJztq0yTyzaMrmRl9OaAoPz63IHV7nUxNdV4ca+D7Zy7/E+u9FGaqNILyLrL RjeETOOQOVxznUrTssRKg/TeS72cG/TWoh6Bjd/o2+NtwSzjC7AamkjDg3DqrraOVj6oInPCDoc u/9HWRMY3QsyUztTQToh7qTGFTbFvd6ZghQFOs7knUmxNw93Ygr2crXr8OkRuhKaY7JrwhwCo53 jcPwr21pcSJctth1UpUAcHjAxgPw3TS9PMgCJy6T+eJ0Q== X-Received: by 127.0.0.2 with SMTP id xMXKYY7687511xxVz8piM8Ea; Wed, 22 May 2024 08:03:38 -0700 X-Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mx.groups.io with SMTP id smtpd.web11.12487.1716390217173034945 for ; Wed, 22 May 2024 08:03:37 -0700 X-Received: from [10.137.194.171] (unknown [131.107.159.43]) by linux.microsoft.com (Postfix) with ESMTPSA id 9C72120B9260; Wed, 22 May 2024 08:03:36 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 9C72120B9260 Message-ID: Date: Wed, 22 May 2024 08:03:36 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [edk2-devel] [PATCH v3 1/1] MdeModulePkg: Add the EFI_RESOURCE_ATTRIBUTE_SPECIAL_PURPOSE attribute To: devel@edk2.groups.io, du.lin@intel.com, "mikuback@linux.microsoft.com" Cc: Liming Gao , "Kinney, Michael D" , "Ni, Ray" References: <20240518005757.1639-1-mikuback@linux.microsoft.com> From: "Oliver Smith-Denny" In-Reply-To: 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 Resent-Date: Wed, 22 May 2024 08:03:37 -0700 Resent-From: osde@linux.microsoft.com Reply-To: devel@edk2.groups.io,osde@linux.microsoft.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: ajX2vRrAUrUuTKMbTVvldFU2x7686176AA= Content-Language: en-CA Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240206 header.b=fjI3rgsh; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=linux.microsoft.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 45.79.224.7 as permitted sender) smtp.mailfrom=bounce@groups.io On 5/21/2024 8:40 PM, Du Lin wrote: > Coherent Device Attribute Table (CDAT) specification defines a EFI memory= type and attribute "EfiConventionalMemory Type with EFI_MEMORY_SP Attribut= e". > Can we still support this type if assigning the GCD memory type "EfiGcdMe= moryTypeReserved" for resource HOBs with the SPECIAL_PURPOSE attribute set? >=20 > CDAT 1.04 specification: https://uefi.org/sites/default/files/resources/C= oherent%20Device%20Attribute%20Table_1.04%20published_0.pdf Thanks for pointing out the CDAT specification. I think one of the issues here is that the PI and UEFI specs are very vague on EFI_MEMORY_SP, to the point that there is no user story on it. This CDAT spec helps close some of the gap, but I think the PI and UEFI spec should be updated to be more verbose in the intended usage of this flag. Does any CDAT code exist in edk2? A naive search didn't turn up anything (and even looking at some of the CXL structures I didn't see any usage outside of the header). Is the intention that the CDAT would be read in PEI and a resource descriptor HOB created from it? If so, I agree this would prevent EfiConventionalMemory from being set. I think the CDAT spec should not be referencing EFI memory types if that is the case, because resource descriptor HOBs deal with resource types, not EFI types, so there is a mismatch. If the CDAT is read at a different time and a resource descriptor HOB is not created from it, then this should not affect it. The reason that GCD reserved type was chosen here was that the assumption for CXL or other remote memory is that UEFI would not want to use it (what if the bus went down and DXE core was allocated there). By marking it reserved with the EFI_MEMORY_SP bit set, we ensure that UEFI does not use it and that the OS knows that this is usable, but the kernel itself may not want to use it, for the same reason (or for performance). Again, the UEFI spec does not describe what memory type this should be, so if there is a different use case here, please do share. 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 (#119115): https://edk2.groups.io/g/devel/message/119115 Mute This Topic: https://groups.io/mt/106165072/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-