From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mx.groups.io with SMTP id smtpd.web09.1147.1654649393923238650 for ; Tue, 07 Jun 2022 17:49:55 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="unable to parse pub key" header.i=@intel.com header.s=intel header.b=PxdLG5d1; spf=pass (domain: intel.com, ip: 134.134.136.100, mailfrom: ray.ni@intel.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1654649393; x=1686185393; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gD8oohgqfONqU78OxaxazEkZGfusn9uyn7cLs4kUaLY=; b=PxdLG5d12Z3IY2OUeylXFCbb0zCHAlW8S3u+iRxZA76ecbizZgAQL/HH Ti7NAD0ceRN3k3XXHJkVeoT48CwGaj0PELfZum3RgD/dW1tkAtAKtCXq3 e3pDyh5mwCVX6XfWbXoxZl/Z3a3+5abmAwH4A1543p5pcesi7ELc4VX25 zse1+77IJ5DQtRRU3j2ItPPkMTuXsPBo46+cVU7zXbslS2g2+xNbPh+g7 EGdIkbIzch6RMGKHd1ghvWybODoXX4vLWYSXLX09bX17tL2I8qjLucrco GicESSOaSWW9kn2116nIv31izP52N4jUFiG8F8zcjFyicGG4HvZqrsL1E w==; X-IronPort-AV: E=McAfee;i="6400,9594,10371"; a="340783104" X-IronPort-AV: E=Sophos;i="5.91,284,1647327600"; d="scan'208";a="340783104" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jun 2022 17:49:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.91,284,1647327600"; d="scan'208";a="683033662" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by fmsmga002.fm.intel.com with ESMTP; 07 Jun 2022 17:49:52 -0700 Received: from orsmsx606.amr.corp.intel.com (10.22.229.19) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Tue, 7 Jun 2022 17:49:51 -0700 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx606.amr.corp.intel.com (10.22.229.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27 via Frontend Transport; Tue, 7 Jun 2022 17:49:51 -0700 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.173) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.27; Tue, 7 Jun 2022 17:49:51 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Qt1lUd6P8JGRotse4Aj6ELlGRTYy14lVST25vYvNnJInw12952zy9cHQd7wgxPyqaQfBNn4iiA4L9nRfcY4mT9gzVlzZCzmmxnoMvFDWyjR9KHo/BLd+/lqz2Mz8hITXs3mgOfqUXhaxaKeDuUL94aRWosAZSGnnzV5bhpOwWn3iGl4/rRG8YOFnvtCZFVSe48Z1MNi//unP1pG8GH2X6fo1sNbHqB3IkIRfQRgWenwzW1OTizKR7Z+6oIdtQ6fnwuDUrxkQewSAKco71ukqAwrJgS3uX+kXS0j7A2hO9259K1jAhJUwAM75c6QUhOXvzK/CE+aoq2lEjgci6lSypQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=oTOZVTE+ls7YhL8gghEuYfRl6GxhGYu08LT7VUM4nOU=; b=E3nTvWJUj9uTDY4pCnLbi/mHKoKMZLwOGFyA18BhBuXXVJGRFtzGDzwfnoMBP4NmChvBeyYyh+WjKQ6O6TMOYMkUE0QU4FVPaXNaWhCqKRYc1JBimgF2/r9HG4nfmKPVDdu49d9cok8ZY0e05VEtFn9JagyL1BLND4QVZdwKrKdZmm5WeLBU3j6y4462R3LzNQ4pE3XpzUWmwYI+PY+wr6ERXJI8BJyR2e3TB1Xdl1wUKiCSEEPS7OV3YzUTQ8rv6/B9Z/Ek1HyaOY68x5+xe5p247acyi9fUwQF5w3ks6L7A/V9jASrGNoWhP3tFSifmm1mD0uZy6BynDl1pfbNVg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from MWHPR11MB1631.namprd11.prod.outlook.com (2603:10b6:301:10::10) by SN6PR11MB2879.namprd11.prod.outlook.com (2603:10b6:805:5c::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.12; Wed, 8 Jun 2022 00:49:48 +0000 Received: from MWHPR11MB1631.namprd11.prod.outlook.com ([fe80::4501:93e1:b65d:684c]) by MWHPR11MB1631.namprd11.prod.outlook.com ([fe80::4501:93e1:b65d:684c%11]) with mapi id 15.20.5314.019; Wed, 8 Jun 2022 00:49:48 +0000 From: "Ni, Ray" To: "devel@edk2.groups.io" , "kraxel@redhat.com" CC: "Liu, Zhiguang" , "Dong, Guo" , "You, Benjamin" , "Rhodes, Sean" Subject: Re: [edk2-devel] [PATCH] UefiPayloadPkg: Always split page table entry to 4K if it covers stack. Thread-Topic: [edk2-devel] [PATCH] UefiPayloadPkg: Always split page table entry to 4K if it covers stack. Thread-Index: AQHYdLDf+pu1rJsysECnhNZXCbSH3q04m1eAgAACBSCAADp9gIAAHPFggAAo/wCAC5s+AA== Date: Wed, 8 Jun 2022 00:49:47 +0000 Message-ID: References: <20220531053937.19696-1-zhiguang.liu@intel.com> <20220531074513.fciegyxkrgiwwqem@sirius.home.kraxel.org> <20220531112147.pvy4d6vetsgsqduu@sirius.home.kraxel.org> <20220531153206.fkq442gz4divb6xa@sirius.home.kraxel.org> In-Reply-To: <20220531153206.fkq442gz4divb6xa@sirius.home.kraxel.org> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.6.500.17 dlp-reaction: no-action dlp-product: dlpe-windows authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9ed87d23-5c8a-489c-033d-08da48e8c9b0 x-ms-traffictypediagnostic: SN6PR11MB2879:EE_ x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iRrX8j/U+3lv31RVagLtFc4Sph94LIfStYk1rVj+afNlB2+1dfzCAwwBRGjyQUSaU7ofhafik0WCB96GbQtF+YheIjohWeTM7WOQIBytkqIOchLEMIM4QcqlF2QKIwWR9hMyN+iGcDSIOuZ2pzJ/lih/7/3lkcU76aikO19Pt43XAklzgEAzJNFlM62g866ef1dYKHAAukY9hHkpvnAZxtOl/zE9qT7qCjbnxCtHY4rbcpH6woOXaHjpKnf87POG+87ZDhO6QDkLVnNzz6a2O76YRlhLf6u23bxx+Ze+KDBLALHmtVxBX6GwIH1lO0a8I8AyJJr6C3s9T0HzmXJgppMV8ijUp7SLTb11cc6mG4BtyW/XIxkKbdhEhQYUjHY+m0O1kGEWAX1fhVO+J/MfSO3uRN5QM1PTQpXuJxrXRtSPjw49rkJIqHtGSOYPCcnFCty46C0gK0fnwv/kMyS4de8GQ0sDZb8kZbY+1qwSeqZTsMZDZ/ne0ezkQU5h9Os3c95KFWIErR672cpoaSJKLzPGSeppwMIr5COm+AfQeW0o9x7NZAkUH2PZKoqCkN53rHkZSIXc8QIM1i2da/3sD6vkai1YUjGpQ/1IE5ynQLuxMDqt3Ka6i9PnQO8FWhBjtBS1a+LL+7QwhqaddNZIAJO/A4hpceIsJlri0OAg9//oyOsgOu4zGa9GGxkIryM0p5rF/4ZwbWJ8sHuB5+ft1oCYTTNbI9Zx9pJMwDacTg3Kyzee2m7/3vNwuWWnYDjwxetn4yywHAVB4M1b8eZEUFP7Fwo/a3Wt/waxRfn69U631j+xcdsIuLZjB8TM532TS+8lekuAbwWMWSSN7zCncA== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MWHPR11MB1631.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230001)(366004)(54906003)(508600001)(110136005)(186003)(71200400001)(66946007)(52536014)(8936002)(122000001)(55016003)(38070700005)(5660300002)(82960400001)(26005)(2906002)(9686003)(86362001)(66556008)(76116006)(66446008)(66476007)(64756008)(316002)(83380400001)(33656002)(38100700002)(8676002)(4326008)(966005)(6506007)(7696005);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?zSHDzc1B/UwkDvwm9WM3H2DqE1EQZbEJ1bB9MjaAS+0EAp8VUkX86NVWZ3c6?= =?us-ascii?Q?xIuyxO4lk6rrsZDNIguSVTKSlY8m1MAF+vtB/zMsw5pumeqCoFuL8/unBuCN?= =?us-ascii?Q?t8NmbiN6Up5ii+XZ4b4Ll2K7ck2F2BBmj/n885AVXZB3jCytjJL03eAFW8gz?= =?us-ascii?Q?3QMHywObtvGd8h5wCc2ORpvf5FBPsE1DtSKrQQ85bNKf3zml97p5rGtTGVVk?= =?us-ascii?Q?pG4d9wMXIpbtdOSyO7VBHYOmVBmv9nuVy5SZFwJudaYQ9I/9ePeWWfrHSwMa?= =?us-ascii?Q?tLpsq5s2gfPgx4ovpxW0B93mjvZQNGeKxJbWlodlyaJNgAjIvNsvPa1I5FMC?= =?us-ascii?Q?7pwyhFT4suoSKEij/CIoh2ql7pao0aYHv11DGKhYa2J8XEJy7BVb0l4D847y?= =?us-ascii?Q?/v5QoSkNcROCrDoxfgWmzQu4jpHzAq96BOoaHVSf5M45QkeSibjwdrVby9cc?= =?us-ascii?Q?Xza9mfaXODd1oYCQEDtmPj3/A0b1nuun/EI9pdoG6t/zWBh+ANvTr4wCTwYo?= =?us-ascii?Q?rkTiZR3YzdbavZgU3mUD/3LVH2oJhwWSkDX1mXil4iD14VZDhfYM3xRKAwDS?= =?us-ascii?Q?ZsXk0g6mRwDrsllLXSCBtMvKc0gEc2wnmSqWfD/P+xN3wceoUo92RrIilYr7?= =?us-ascii?Q?OvK2qWyrlmozR4876ZHfSIrn4Gydl85eSY/AaEKpV5IJ6bAdXE1m7XnI+EdT?= =?us-ascii?Q?owTv/6v9BAXjYSZiiZMB/AiBtK1LPRAliPCpJvE3riDoL2mGQ9OUuWlzHCSx?= =?us-ascii?Q?WHfYwWk3j/p0Wnt1zNTGI4u3U4mD8JbNJZ2lNvzelagF4iGZhCM/JXRp4LCw?= =?us-ascii?Q?JUCHvA8HvBzyICwEk6ckJ8H8//qoBzIC5k266ztNxW1qtCzCfOEGp3aqKLa3?= =?us-ascii?Q?/8hvvcHWbj+xGEq9nuf8LZ7W4SdiYxbPC11w3h6EiuwCn6lHnpHtjvknw7uQ?= =?us-ascii?Q?R5R+ZDmPE+rPdVTXMrFLMLGzLteVV5OvEPhsKqljMeBqOr01en89eDYqvsfb?= =?us-ascii?Q?sH9r10MFsez/Np8taMfQjSGcw9iLrpVcBBwX+r6k2UlYqxMzw8uK4Ypz2smp?= =?us-ascii?Q?Uqh6yaZH/j/t3BfiIEc7QYUqVCDEdn3tGxmdcVZYsR8gcnryCXdgTaszPsQn?= =?us-ascii?Q?S5xsU0zy8zxaNQxVeXrf41VKF5H2j8lEeOcKXkF1khkEc+uJuIIU3Ck1DZ2I?= =?us-ascii?Q?WAQNs5SjZOHNAAkAvaoLhwNgMil+HbV4HINkVJHmaytODR2wasTb9cYEhSXZ?= =?us-ascii?Q?HBAnpd27D9UllmkQuNzFr4LtYQmtVpHQYU8Vrh0Oy2WpHHNNalCZWeyplBme?= =?us-ascii?Q?fxhKqo2MBm4GmaFqd2kAM7p2lIrh4U4NM8QFD726aY7FrnuaijN8LPU5A5CO?= =?us-ascii?Q?XdhB71KpjbC1TpFAJRCZpy0uqiz+at5y6gNf7bMGa8sklxHZg1Yh+Fl4B1LU?= =?us-ascii?Q?Npn3qJq9xFQpxVKzGCN3lK4MleO8qnBh5/R20P80m0pUqXm95Q/1ItU7Ldin?= =?us-ascii?Q?tyCiIWc5fiGO7VGontgFn8OF09Ufa+SLSDk+nTRoQr2BkwFdAVLWGSALkJTT?= =?us-ascii?Q?mM1zqhCESGI69KNTBslAiqUTsbjX8jy+ryZ388d15qE1TNjLe1dfahsTKkU6?= =?us-ascii?Q?9vJz6QJ1sQADQbRToa7DBMHvg02eF1eEEvjfRDvk8INv2Ylul4a604QFxssr?= =?us-ascii?Q?BeUI7rbUwvS+Nr+f+WpFXxIpJw3ZUwyATx4cWIH5+uVXS3WQ+EsJqWQwtLhD?= =?us-ascii?Q?F7i+ftObLg=3D=3D?= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1631.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9ed87d23-5c8a-489c-033d-08da48e8c9b0 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2022 00:49:47.9245 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: e1QXNH2aqqEgrNsvCjhBOySyxVTKxKjig3pGshzy8Drw3BN9sxjJxYbZSiolbvRR4h3QRMYUmwFdDLkFAnzaGg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2879 Return-Path: ray.ni@intel.com X-OriginatorOrg: intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Hi, >=20 > > yes:) Actually there is no split at all. The 4K page table is created i= n the very beginning(before setting to cr3). > > So, no TLB cache issue at all. >=20 > > > I think doing a linux-style page split will be the more robust soluti= on. > > > > Thanks for explaining the linux behavior. > > > > Intel's SDM also contain below wordings: > > * As noted in Section 4.10.2, the TLBs may subsequently contain multipl= e translations for the address range if > > * software modifies the paging structures so that the page size used fo= r a 4-KByte range of linear addresses > > * changes. A reference to a linear address in the address range may use= any of these translations. >=20 > This is probably the section the "only safe if [ ... ] the two entries > [ ... ] identical" part refers to. >=20 > > * Software wishing to prevent this uncertainty should not write to a pa= ging-structure entry in a way that would > > * change, for any linear address, both the page size and either the pag= e frame, access rights, or other attributes. > > * It can instead use the following algorithm: first clear the P flag in= the relevant paging-structure entry (e.g., > > * PDE); then invalidate any translations for the affected linear addres= ses (see above); and then modify the > > * relevant paging-structure entry to set the P flag and establish modif= ied translation(s) for the new page size. >=20 > So linux basically implements this recommendation. >=20 > > But I still have some doubts about using linux-style page split. > > Because it's marked as not present: > > 1. Active code should not access data in the 2M region (stack is in the= 2M region in our case) > > 2. Active code should not in the 2M region (how to guarantee that?) > > > > How does Linux guarantee the above two points? >=20 > Easy. It's kernel code changing mappings for userspace, so no need to > worry about code removing its own mappings in the first place. It's a > different story for edk2 though ... >=20 > Can this be covered by the page fault handler? Update the entry like > the current code does, except for clearing the present bit, then flush > tlb, then set the present bit. In case we take a page fault the only > action the handler must do is enable the present bit, which might even > be possible to do without additional state tracking. It's a bit heavy from my perspective. I prefer to split the page to 4K in the very beginning of stack setup. It also guarantees such issue doesn't appear. >=20 > Linux most likely has something simliar in the page fault handler. > Linux needs it for a different reason, it must handle SMP races. When > temporary clearing the present bit linux might get a page fault on > *another* cpu which runs userspace code touching the page being updated. >=20 > take care, > Gerd >=20 >=20 >=20 >=20 >=20