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 CA6B3AC1706 for ; Tue, 11 Jun 2024 17:53:39 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=43aszP1oyeJAt+w4/mPdcSie7Zc0xG8/c/nT+0SkVl8=; c=relaxed/simple; d=groups.io; h=DKIM-Filter:Message-ID:Date:MIME-Version:User-Agent:Subject:To: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=1718128419; v=1; b=HNm7jJ6qMfNuhXkWbWzilt/wNoXIXx5OPYXbFetA6Fqt8zvTjYAmfNjfyauuzY9kW+czxwCQ ucznrQYF9Iy/BzFAaeFq6J9m9gtuIGBHpHxvSutsd0eYluwjo6yyV4SMJM1jDlhAhoVyX7rdHWK ZdkyWddD25ilacuSFF9Lx1YcgxOnnNvGSp81uEqT86dWp/GuaJhjNBNLIMtCTfEufVixWoelEYl VU0Zc53FL5SQkH4WKVXI9OTbm2xbciHjf7JbEWVP+rRYYg4FUD1gvJe2u38E/H23UEXb4L/pMHa p5dor2ajG17nd0Yq65VKdMoN9dOH2r9DZKL2KV2wcfCcg== X-Received: by 127.0.0.2 with SMTP id AhKCYY7687511xdbcCtqh3Ti; Tue, 11 Jun 2024 10:53:38 -0700 X-Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mx.groups.io with SMTP id smtpd.web11.764.1718128417566200598 for ; Tue, 11 Jun 2024 10:53:37 -0700 X-Received: from [10.137.194.171] (unknown [131.107.159.43]) by linux.microsoft.com (Postfix) with ESMTPSA id 0E8F720B915A; Tue, 11 Jun 2024 10:53:37 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 0E8F720B915A Message-ID: Date: Tue, 11 Jun 2024 10:53: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, michael.d.kinney@intel.com, "dhaval@rivosinc.com" , Michael Kubacki References: <20240518005757.1639-1-mikuback@linux.microsoft.com> <24273.1717983877551380256@groups.io> 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: Tue, 11 Jun 2024 10:53: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: ALEUjov7YNIM3ne8I8LWbt9Wx7686176AA= Content-Language: en-US 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=HNm7jJ6q; 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 Hi Mike, This conversation has gotten a little fragmented across this thread and Dhaval put up a PR I commented on :). On 6/11/2024 10:30 AM, Michael D Kinney wrote: > Hi Oliver, >=20 > The DXE Core already has a policy to auto convert untested memory to > tested memory if the DXE Core runs out of memory. >=20 Yeah, this was my suggestion on Dhaval's PR, that we follow a similar memory promotion with EFI_MEMORY_SP as we do with untested memory. I was planning to write this up, but haven't gotten to it yet. > Should we have a different memory type to allocate memory with the > EFI_MEMORY_SP attribute? There is a lot of ambiguity in the PI/UEFI specs around what memory types EFI_MEMORY_SP can be. This is further complicated by the CDAT spec which uses EDKII-isms in defining the memory type (which it probably shouldn't). Amongst the various groups I have been chatting with (OS folks, this mailing thread, firmware folks), there does seem to be a consensus that the UEFI spec, at least, needs clarification here, as currently it just says this attribute means special memory, which of course in and of itself means nothing :). However, these systems don't really exist yet. As these discussions continue, I am changing my opinion to say less is more, for now. I think we can't do too much architecting yet without knowing what these systems are going to look like and what OSes will expect. If we get to a point where we have systems with only remote attached memory (or the vast majority remote attached memory) then having a separate memory type probably does make sense. It would also solve the unenlightened OS case where it wouldn't use SP memory if it was a new memory type, whereas just the attribute on EfiConventionalMemory will have an unenlightened OS use the memory. >=20 > What would be the side effects of performing general allocations from > memory with the EFI_MEMORY_SP attribute? If there are potentially bad > side effects, then the DXE Core should never allocate from those > ranges and it is up to the platform to make sure there is enough normal > memory to boot. >=20 Right, I think we don't know enough yet, and so defaulting to UEFI not using the memory and letting these systems mature a bit makes sense. Inevitably if we build something now before these systems are fleshed out, we will have built something that doesn't quite work. 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 (#119553): https://edk2.groups.io/g/devel/message/119553 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-