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 B9248941D16 for ; Wed, 21 Feb 2024 21:44:36 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=mMAjROXre976JE4osEg8WqUreQL8snQS5X367E1VJ9Y=; c=relaxed/simple; d=groups.io; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Transfer-Encoding; s=20140610; t=1708551875; v=1; b=AhzRcQD41IyoJ/OGW12D3q/8u4OfN07Svkupd4auT3DpYn1BCXblIuabJFNDc9EFHnvRy16e c90Tmm/Szl6RwKwX8dsk2UpB/V8zYRxu5NILKT3PhabnU9JH1voIQ4I1AInot8ntyFqATNMraNt f7+2JtH+6m4UZEXi6qsXybRw= X-Received: by 127.0.0.2 with SMTP id jqx7YY7687511xySaJhQnqVY; Wed, 21 Feb 2024 13:44:35 -0800 X-Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com [209.85.217.43]) by mx.groups.io with SMTP id smtpd.web10.803.1708551874590842743 for ; Wed, 21 Feb 2024 13:44:34 -0800 X-Received: by mail-vs1-f43.google.com with SMTP id ada2fe7eead31-4703e4d53b6so124711137.1 for ; Wed, 21 Feb 2024 13:44:34 -0800 (PST) X-Gm-Message-State: wVE6CrEp11ElswrhxrEIxLXsx7686176AA= X-Google-Smtp-Source: AGHT+IGmF1UKki0L/1HNu10DcjutPDChbKMrQMMEavTZh3AgeFbSON89kjQKVZp1RLRyxJH0Z/WTZl7RUFo9yuDO7lE= X-Received: by 2002:a05:6102:f85:b0:470:62cc:6306 with SMTP id e5-20020a0561020f8500b0047062cc6306mr902928vsv.6.1708551873263; Wed, 21 Feb 2024 13:44:33 -0800 (PST) MIME-Version: 1.0 References: <20240221012513.27453-1-jianfeng.zhou@intel.com> <6bf89071-0514-cb97-f639-6bece14cc6d7@redhat.com> In-Reply-To: <6bf89071-0514-cb97-f639-6bece14cc6d7@redhat.com> From: "Pedro Falcato" Date: Wed, 21 Feb 2024 21:44:21 +0000 Message-ID: Subject: Re: [edk2-devel] [PATCH] UefiCpuPkg: add volatile qualifier to page table related variable To: devel@edk2.groups.io, lersek@redhat.com Cc: Zhou Jianfeng , Ray Ni , Rahul Kumar , Gerd Hoffmann 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,pedro.falcato@gmail.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=AhzRcQD4; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=gmail.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 On Wed, Feb 21, 2024 at 8:36=E2=80=AFPM Laszlo Ersek wr= ote: > > On 2/21/24 02:25, Zhou Jianfeng wrote: > > Add volatile qualifier to page table related variable to prevent > > compiler from optimizing away the variables which may lead to > > unexpected result. > > > > Signed-off-by: Zhou Jianfeng > > Cc: Ray Ni > > Cc: Laszlo Ersek > > Cc: Rahul Kumar > > Cc: Gerd Hoffmann I'd appreciate getting CC'd on my own suggestion.... > > --- > > UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c | 12 ++++++------ > > 1 file changed, 6 insertions(+), 6 deletions(-) > > (1) subject should be something like: > > UefiCpuPkg/CpuPageTableLib: qualify page table accesses as volatile > > > > > diff --git a/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c b/Uef= iCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c > > index 2ea40666cc..5cf6e8fea0 100644 > > --- a/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c > > +++ b/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c > > @@ -26,7 +26,7 @@ PageTableLibSetPte4K ( > > IN IA32_MAP_ATTRIBUTE *Mask > > ) > > { > > - IA32_PTE_4K LocalPte4K; > > + volatile IA32_PTE_4K LocalPte4K; > > > > LocalPte4K.Uint64 =3D Pte4K->Uint64; > > if (Mask->Bits.PageTableBaseAddressLow || Mask->Bits.PageTableBaseAd= dressHigh) { > > @@ -78,7 +78,7 @@ PageTableLibSetPte4K ( > > } > > > > if (Pte4K->Uint64 !=3D LocalPte4K.Uint64) { > > - Pte4K->Uint64 =3D LocalPte4K.Uint64; > > + *(volatile UINT64 *)&(Pte4K->Uint64) =3D LocalPte4K.Uint64; > > } > > } > > > > @@ -100,7 +100,7 @@ PageTableLibSetPleB ( > > IN IA32_MAP_ATTRIBUTE *Mask > > ) > > { > > - IA32_PAGE_LEAF_ENTRY_BIG_PAGESIZE LocalPleB; > > + volatile IA32_PAGE_LEAF_ENTRY_BIG_PAGESIZE LocalPleB; > > > > LocalPleB.Uint64 =3D PleB->Uint64; > > if (Mask->Bits.PageTableBaseAddressLow || Mask->Bits.PageTableBaseAd= dressHigh) { > > @@ -154,7 +154,7 @@ PageTableLibSetPleB ( > > } > > > > if (PleB->Uint64 !=3D LocalPleB.Uint64) { > > - PleB->Uint64 =3D LocalPleB.Uint64; > > + *(volatile UINT64 *)&(PleB->Uint64) =3D LocalPleB.Uint64; > > } > > } > > > > @@ -200,7 +200,7 @@ PageTableLibSetPnle ( > > IN IA32_MAP_ATTRIBUTE *Mask > > ) > > { > > - IA32_PAGE_NON_LEAF_ENTRY LocalPnle; > > + volatile IA32_PAGE_NON_LEAF_ENTRY LocalPnle; > > > > LocalPnle.Uint64 =3D Pnle->Uint64; > > if (Mask->Bits.Present) { > > @@ -231,7 +231,7 @@ PageTableLibSetPnle ( > > LocalPnle.Bits.WriteThrough =3D 0; > > LocalPnle.Bits.CacheDisabled =3D 0; > > if (Pnle->Uint64 !=3D LocalPnle.Uint64) { > > - Pnle->Uint64 =3D LocalPnle.Uint64; > > + *(volatile UINT64 *)&(Pnle->Uint64) =3D LocalPnle.Uint64; > > } > > } > > I agree with the idea (I think it's a necessary change, or put > differently, an improvement, even though I may not be convinced that it > is a *sufficient* improvement; but let's not rehash all that here > again); however, I think the implementation is not the greatest. > > Volatile-qualifying the local variables does not seem useful for > anything. It's fine -- actually: it's beneficial -- if the compiler > optimizes accesses to those locals -- being on the stack -- as heavily > as it can. In other words, those parts of the patch look like a small > performance regression. > > (2) What we want to qualify as volatile here are the *targets* of the > Pte4K, PleB and Pnle pointers. Your other patch ("UefiCpuPkg: Fix IN OUT > parameters marked as IN") correctly marks those as "IN OUT", so in this > patch, we should update them to: > > IN OUT volatile IA32_PAGE_NON_LEAF_ENTRY *Pnle > > and similar. Then the existent assignment expressions > > Pnle->Uint64 =3D LocalPnle.Uint64; > > don't have to be changed. I echo these comments :) > > Note that call sites will not have to be updated either; see C99 6.3.2.3 > Pointers, paragraph 2: > > For any qualifier q, a pointer to a non-q-qualified type may be > converted to a pointer to the q-qualified version of the type; the > values stored in the original and converted pointers shall compare > equal. Ugh, honestly converting to volatile implicitly is kind-of yucky, but I guess it works; personally I'd rather have explicit conversion, but it's just a matter of taste. What I *really* prefer in these cases (when we're not dealing with MMIO) is something like READ_ONCE and WRITE_ONCE, where the "volatility points" are very well annotated, but oh well :) --=20 Pedro -=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 (#115743): https://edk2.groups.io/g/devel/message/115743 Mute This Topic: https://groups.io/mt/104483610/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-