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 6FA98740035 for ; Wed, 7 Feb 2024 17:53:14 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=z9wwSTsDq76GrSqJIT3JZt3gDvWjH+Kff5b8cUI+L9I=; 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=1707328392; v=1; b=rocF8hT4MPrHnkGvXxky+o6J+O5k+Qh3THXkyE64ZiIioQjkubaGjBaUWR3X8FMHUI/fym+k S6Tw4zJs1LCaWlL/C/6zPOeTuZ/kBl+tO6bgeilMepGrwyEQSRES7z5RL1hoLfQ5lZWnYb5T3rU r2S/LauyTep8sZn9MutWnLpE= X-Received: by 127.0.0.2 with SMTP id SISCYY7687511xTWrIPCW3Y4; Wed, 07 Feb 2024 09:53:12 -0800 X-Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) by mx.groups.io with SMTP id smtpd.web11.4476.1707328392169571944 for ; Wed, 07 Feb 2024 09:53:12 -0800 X-Received: by mail-vs1-f47.google.com with SMTP id ada2fe7eead31-46d336f8081so225321137.0 for ; Wed, 07 Feb 2024 09:53:12 -0800 (PST) X-Gm-Message-State: JeJMMnxhe5fK8geuPxWElABBx7686176AA= X-Google-Smtp-Source: AGHT+IFKzZ4jir4fVLsp+rMfXEzFLJ3SUGT0nwoiMCDpioJY3d44m9opibVRXMVRI2OSK1J/c3FmSGg5vZgAXrxtIuc= X-Received: by 2002:a05:6102:312a:b0:46d:1c19:e76e with SMTP id f10-20020a056102312a00b0046d1c19e76emr2883693vsh.35.1707328391152; Wed, 07 Feb 2024 09:53:11 -0800 (PST) MIME-Version: 1.0 References: <20240205140345.1437-1-dun.tan@intel.com> <20240205140345.1437-2-dun.tan@intel.com> In-Reply-To: From: "Pedro Falcato" Date: Wed, 7 Feb 2024 17:52:59 +0000 Message-ID: Subject: Re: [edk2-devel] [PATCH 1/3] UefiCpuPkg: Reduce and optimize access to attribute To: "Zhou, Jianfeng" Cc: "devel@edk2.groups.io" , "lersek@redhat.com" , "Tan, Dun" , "Ni, Ray" , "Kumar, Rahul R" , 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=rocF8hT4; 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 7, 2024 at 1:57=E2=80=AFAM Zhou, Jianfeng wrote: > > Hi Pedro, > > >> AFAIK, it's not allowed as IIRC APs cannot run arbitrary EFI boot ser= vices code. > [Zhou] The scenario I mentioned/The case we hit is during BIOS boot, not = software after EndOfBootService. I know, but the PI spec mentions (in the EFI_MP_SERVICES section) that you need to be careful and can't call EFI code willy-nilly, which is why (most) EFI code does not need to handle concurrency and locking. > > >> 1) Your fix is not correct. The compiler can tear your store, you nee= d to use a volatile store for this. > [Zhou] Assembly code of function PageTableLibSetPnle attached. The code i= s expected. > Can't get "need to use a volatile store for this", would you pleas= e share more detail about it? The compiler (and this is defined by the C spec) does not know that your write has side effects. As such, it can re-order it, delete it, split it in half, etc. Say, for example: UINT64 gGlobal; UINT64 gGlobal2; VOID Foo (VOID) { gGlobal =3D 10; gGlobal2 =3D 20; } The compiler can legally generate this (I hope i get the intel syntax right, i usually write AT&T :)): mov qword ptr [gGlobal2], 20 mov qword ptr [gGlobal], 10 or mov dword ptr [gGlobal2], 20 mov dword ptr [gGlobal2 + 4], 0 mov dword ptr [gGlobal], 10 mov dword ptr [gGlobal + 4], 0 or any other variant, because "there are no side effects". With volatile, the compiler knows there are side-effects so the optimization it can do is quite limited. > > >> 2) What kind of page table manipulation is happening while APs are ru= nning code, and does this mean you need a TLB shootdown mechanism? > [Zhou] a) happened while split 2M Page to 4K to make full use of memory:= it is long story. > Anyway, the bit operation code is unexpected, and my change is h= armless. > b) my understanding, TLB shootdown mechanism not suitable for this= case. It's too late to "shootdown". AP might exception before "shootdown" This is a parallel concern to this patch. If you're running other APs and changing page table entries you *need* to shoot their TLB entries down, for correctness. Or at least make sure that when an AP goes to execute code, the TLB is completely synchronized (by, say, a CR3 reload in every AP right after a wakeup). --=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 (#115241): https://edk2.groups.io/g/devel/message/115241 Mute This Topic: https://groups.io/mt/104176232/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-