From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by mx.groups.io with SMTP id smtpd.web11.7711.1665417056458078350 for ; Mon, 10 Oct 2022 08:50:56 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@google.com header.s=20210112 header.b=D3Fapnen; spf=pass (domain: google.com, ip: 209.85.218.49, mailfrom: dionnaglaze@google.com) Received: by mail-ej1-f49.google.com with SMTP id k2so25796800ejr.2 for ; Mon, 10 Oct 2022 08:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=70LGzd9D0J858EUbge51Sn0tlWFwkQwe4krsBqU3qn8=; b=D3FapnenBT3d7vOS7G8Kw0jDqBpW4/SfkGc0PPvtc5YSEC03cXxq638oPqHf0ujFxD GQshmgCXJd9HukRFA9NOWIs/jELWfgsIjwdp4Gqh4fuc0UqRO8BAIKDfz1R+L4Qg6BAA 4GJsdq/r03uJP1TTubpwDiCGuKRd817vrxS0MXK9iSZSOWF++gtEsz5ZtaI7oVnKUpRg wHyAGOxPKXN7B9zl6OOVWfI1AktfrlvapngAtJOWFTxKpT34TFq04QabC4s+sBHxAkj7 POGyPPUBX6hJMULvdvu6MRmDBkki8hUwgUgcd2XYasChnNQ2/Tpho1oUoBJi9Jph5MeK l4jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=70LGzd9D0J858EUbge51Sn0tlWFwkQwe4krsBqU3qn8=; b=T1P3tcjBiTmeG2Tr8GCNaeET5GbDgLSNbKj/c4so4CpRjb1f9EHtqyvZRwBTGYXXk6 xO8q8VsvT/xS1+/32lcEYD/UrUXn0A4XTFg01GdAlgmdjMcb0cTRiiaVoG7YxoT4qtqg 7/xp+Qlzupg6957/gWK91DcLLUVpGK2lSMVDgYahvyeoqtbeSRKj273aVpFibbKTbcbi nr/jx5EJmR8EQDL67GXF+nKc+uls6nxmXB8LmD4uxO2rdkllewUhISBsAjvls5lzpo5z HJe9zkTK9an9sLFI3t4fJVjc5VFaY7r+nMyg+FTAcVsSalYc/OVUKN4BEFWQFAB18EL/ Ut6A== X-Gm-Message-State: ACrzQf0VfR4sQSmVzuvvDdz2P/pg5NQBT/WKf4Vl06BjFJGdD27qTILx aPBBUtDBcE9I9ivDGvXCFm9U7gPRgX63KBr7wTfOuQ== X-Google-Smtp-Source: AMsMyM576ZJD4sgWMoS0FfE0zthxbiXh0Y6AJd/uHERgJyAwgY+nSAT3RMvCsfCHPDwTC+5LN/HCG20E8NmFiJ2sokY= X-Received: by 2002:a17:906:9b87:b0:733:1795:2855 with SMTP id dd7-20020a1709069b8700b0073317952855mr15524931ejc.156.1665417054772; Mon, 10 Oct 2022 08:50:54 -0700 (PDT) MIME-Version: 1.0 References: <01f901d8dc4f$e9beeac0$bd3cc040$@byosoft.com.cn> In-Reply-To: From: "Dionna Glaze" Date: Mon, 10 Oct 2022 08:50:43 -0700 Message-ID: Subject: =?UTF-8?B?UmU6IFtlZGsyLWRldmVsXSDlm57lpI06IFtQQVRDSCBWNCAwMC8xMF0gSW50cm9kdWNlIExhenktYWNjZXB0IGZvciBUZHggZ3Vlc3Q=?= To: "Ni, Ray" Cc: "Xu, Min M" , "devel@edk2.groups.io" , "Gao, Liming" , "Gao, Zhichao" , "Aktas, Erdem" , Gerd Hoffmann , James Bottomley , "Yao, Jiewen" , Tom Lendacky , "Gao, Jiaqi" , "Wang, Jian J" , "Liu, Zhiguang" , "Kinney, Michael D" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > Can OS call AcceptMemory protocol for those ranges that are not accepted? > AcceptMemory is not specified to avoid accepting previously accepted memory. As I understand it, AcceptMemory is purely a hardware abstraction layer for CC technologies inside the UEFI implementation. It additionally is not meant to modify address spaces. Address space modification happens around it. Gao has a point though, that the two could be combined. I'm not sure if it's particularly helpful to expose AcceptMemory to the OS. Exposing it I think would necessitate changing its semantics to be safer, e.g., Use the insight that AcceptMemory is only used to accept full or partial regions of unaccepted memory spaces: /** * Accepts memory in page granularity from the beginning of a pointed-to memory descriptor, and changes * the type of the affected memory range to EfiConventionalMemory. * * @param[This] This A pointer to this protocol instance * @param[AddressInSpace] An address within the memory descriptor from which to accept pages. * @param[NumPages] The amount of EFI_PAGE_SIZE blocks of memory to accept from the memory * descriptor's beginning and convert into EfiConventionalMemory. If pages remain in the memory descriptor * after acceptance, the remaining memory will start at the initial memory descriptor's * start address + NumPages * EFI_PAGE_SIZE * with type EfiUnacceptedMemory. * The changes to the memory map affect only the memory descriptor named by AddressInSpace. * * Returns EFI_INVALID_PARAMETER if AddressInSpace names to a memory descriptor that is not * EfiUnacceptedMemory, or if the named memory descriptor is not at least NumPages in size. */ EFI_STATUS EFIAPI AcceptFromMemorySpaceBeginning ( IN ProtocolType *This, IN EFI_VIRTUAL_ADDRESS AddressInSpace, IN UINTN NumPages ); /** * To be called by the OS loader to indicate that it supports and accepts responsibility for EfiUnacceptedMemory. * * Without calling this function, ExitBootServices will accept all unaccepted memory before returning. This * behavior maintains safety for OSes that do not support unaccepted memory or know of this protocol. */ VOID EFIAPI DisableAcceptAllOnExitBootServices (IN ProtocolType *This); I think this could be a fine protocol to expose to the OS loader since it would be safer written this way, albeit AcceptFromMemorySpaceBeginning is rather redundant for the behavior that the OS would need to implement if it calls the disable function. I'm not too pleased about the naming behavior, but I also don't really like requiring the interface to only accept the start address of any particular memory descriptor. That's a matter of taste though. The implementation of the memory descriptor search would not be much more complicated than a couple inequality checks instead of a single equality check. I don't think it's worth the effort in this interface to allow an arbitrary range that could split a single memory descriptor into at most three instead of at most two, since it is logic I don't think would be readily exercised. Given that we're talking about calling this function given knowledge of the MemoryMap, and that the MemoryMap should be condensed to not have separate memory descriptors that could be coalesced, I think the limitation that NumPages fits within the single descriptor is reasonable. All this being said, what's the value of combining the protocols? One fewer header and guid? I honestly don't know since I haven't been around long enough to understand how these kinds of things evolve and create possible warts. If it's just two two things though, I think a header and guid are worth avoiding confusion by exposing AcceptMemory unnecessarily. > > -----Original Message----- > > From: Xu, Min M > > Sent: Monday, October 10, 2022 11:08 AM > > To: devel@edk2.groups.io; Dionna Amalie Glaze ; > > Gao, Liming > > Cc: Gao, Zhichao ; Ni, Ray ; > > Aktas, Erdem ; 'Gerd Hoffmann' > > ; 'James Bottomley' ; Yao, > > Jiewen ; 'Tom Lendacky' > > ; Gao, Jiaqi ; Wang, Jian > > J ; Liu, Zhiguang ; Kinn= ey, > > Michael D ; Xu, Min M > > Subject: RE: [edk2-devel] =E5=9B=9E=E5=A4=8D: [PATCH V4 00/10] Introduc= e Lazy-accept for > > Tdx guest > > > > On October 10, 2022 10:28 AM, Gao Liming wrote: > > > > > > Min: > > > I have no comments for new unaccepted resource type and unaccepted > > gcd > > > type. In fact, they are mapping to UEFI EfiUnacceptedMemoryType. > > > > > > For new protocol EfiMemoryAcceptProtocol, I see another patch seria= l > > > https://edk2.groups.io/g/devel/message/94763 base on it to introduce > > > ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL. Can these two > > protocols > > > be combined into one? > > > > > EfiMemoryAcceptProtocol looks like this: > > typedef > > EFI_STATUS > > (EFIAPI *EDKII_ACCEPT_MEMORY)( > > IN EDKII_MEMORY_ACCEPT_PROTOCOL *This, > > IN EFI_PHYSICAL_ADDRESS StartAddress, > > IN UINTN Siz= e > > ); > > This protocol is called to accept the memory based on the input start a= ddress > > and size. > > > > While ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL looks like below: > > typedef > > EFI_STATUS > > (EFIAPI *BZ3987_DISABLE_ACCEPT_ALL_UNACCEPTED_MEMORY)( > > IN BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL *This > > ); > > According to its description (https://edk2.groups.io/g/devel/message/94= 768) > > this protocol is used to disable the behavior of accepting all unaccept= ed > > memory. And it is designed to be called by the OS loader, not EDK2 itse= lf. > > > > I am afraid these 2 protocols cannot be combined into one. > > > > Dionna what's your thought? > > > > Thanks > > Min --=20 -Dionna Glaze, PhD (she/her)