From: "Ni, Ray" <ray.ni@intel.com>
To: "Tan, Dun" <dun.tan@intel.com>,
"devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: "Dong, Eric" <eric.dong@intel.com>,
"Kumar, Rahul R" <rahul.r.kumar@intel.com>,
Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Patch V6 04/22] UefiCpuPkg/CpuPageTableLib: Fix the non-1:1 mapping issue
Date: Fri, 24 Mar 2023 14:03:40 +0000 [thread overview]
Message-ID: <MN6PR11MB82447B8999A30C805D9931818C849@MN6PR11MB8244.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20230324085151.1237-2-dun.tan@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
> -----Original Message-----
> From: Tan, Dun <dun.tan@intel.com>
> Sent: Friday, March 24, 2023 4:52 PM
> To: devel@edk2.groups.io
> Cc: Dong, Eric <eric.dong@intel.com>; Ni, Ray <ray.ni@intel.com>; Kumar,
> Rahul R <rahul.r.kumar@intel.com>; Gerd Hoffmann <kraxel@redhat.com>
> Subject: [Patch V6 04/22] UefiCpuPkg/CpuPageTableLib: Fix the non-1:1
> mapping issue
>
> In previous code logic, when splitting a leaf parent entry to
> smaller granularity child page table, if the parent entry
> Attribute&Mask(without PageTableBaseAddress field) is equal to the
> input attribute&mask(without PageTableBaseAddress field), the split
> process won't happen. This may lead to failure in non-1:1 mapping.
>
> For example, there is a page table in which [0, 1G] is mapped(Lv4[0]
> ,Lv3[0,0], a non-leaf level4 entry and a leaf level3 entry). And we
> want to remap [0, 2M] linear address range to [1G, 1G + 2M] with the
> same attibute. The expected behaviour should be: split Lv3[0,0]
> entry into 512 level2 entries and remap the first level2 entry to
> cover [0, 2M]. But the split won't happen in previous code since
> PageTableBaseAddress of input Attribute is not checked.
>
> So, when checking if a leaf parent entry needs to be splitted, we
> should also check if PageTableBaseAddress calculated by parent entry
> is equal to the value caculated by input attribute.
>
> Signed-off-by: Dun Tan <dun.tan@intel.com>
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Ray Ni <ray.ni@intel.com>
> Cc: Rahul Kumar <rahul1.kumar@intel.com>
> Tested-by: Gerd Hoffmann <kraxel@redhat.com>
> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
> UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c | 12
> +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> b/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> index 127b65183f..b94ef07c56 100644
> --- a/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> +++ b/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> @@ -274,6 +274,8 @@ PageTableLibMapInLevel (
> IA32_MAP_ATTRIBUTE ChildMask;
> IA32_MAP_ATTRIBUTE CurrentMask;
> IA32_MAP_ATTRIBUTE LocalParentAttribute;
> + UINT64 PhysicalAddrInEntry;
> + UINT64 PhysicalAddrInAttr;
>
> ASSERT (Level != 0);
> ASSERT ((Attribute != NULL) && (Mask != NULL));
> @@ -341,7 +343,15 @@ PageTableLibMapInLevel (
> // This function is called when the memory length is less than the region
> length of the parent level.
> // No need to split the page when the attributes equal.
> //
> - return RETURN_SUCCESS;
> + if (Mask->Bits.PageTableBaseAddress == 0) {
> + return RETURN_SUCCESS;
> + }
> +
> + PhysicalAddrInEntry =
> IA32_MAP_ATTRIBUTE_PAGE_TABLE_BASE_ADDRESS (&PleBAttribute) +
> MultU64x32 (RegionLength, (UINT32)PagingEntryIndex);
> + PhysicalAddrInAttr =
> (IA32_MAP_ATTRIBUTE_PAGE_TABLE_BASE_ADDRESS (Attribute) + Offset)
> & (~RegionMask);
> + if (PhysicalAddrInEntry == PhysicalAddrInAttr) {
> + return RETURN_SUCCESS;
> + }
> }
>
> ASSERT (Buffer == NULL || *BufferSize >= SIZE_4KB);
> --
> 2.31.1.windows.1
next prev parent reply other threads:[~2023-03-24 14:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-24 8:51 [Patch V6 00/22] Fix issues in CpuPageTableLib duntan
2023-03-24 8:51 ` [Patch V6 04/22] UefiCpuPkg/CpuPageTableLib: Fix the non-1:1 mapping issue duntan
2023-03-24 14:03 ` Ni, Ray [this message]
2023-03-24 8:51 ` [Patch V6 06/22] UefiCpuPkg/CpuPageTableLib: Fix issue when splitting leaf entry duntan
2023-03-24 14:03 ` Ni, Ray
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=MN6PR11MB82447B8999A30C805D9931818C849@MN6PR11MB8244.namprd11.prod.outlook.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox