From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web11.9889.1685525054995392405 for ; Wed, 31 May 2023 02:24:15 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=pNqFJi48; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6A33862E26 for ; Wed, 31 May 2023 09:24:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CC308C4339B for ; Wed, 31 May 2023 09:24:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1685525053; bh=KrN97z+sicLTsHv3ncmVZUhJHv7CtMQoB3rF0tDmeqc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=pNqFJi48HbkGB7VKFePR3gRhPatfRd7Okt81+wWS4LU9rVmVMPOpZfqbeFbX/LVp8 CJk+/9w3Qk5ceCpJAvtopxSlD2G5ylkrm2aTP0ef62QHE3nMDOIJYi1d1suqk2gISK OhFUSxHhZ/KzTsX7OgosuaMr+cvwqpsI7d0N0TsUEWy52aw/eaS5T1TcNEzCexUU5J EW+EWQ+jN7mBufHEtrmaodNin7S/8sakPxNb8nFr3yj/PkwqqmmaC2q9Zsf4jbS4/d SpAHUTDrIbZm2MUOomBlb8U2DxldwQt5khXkPbeUI1xCm6UMf+VzePSN6LE955Lpuw vDvEtbUxEZWlg== Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-2af20198f20so57868431fa.0 for ; Wed, 31 May 2023 02:24:13 -0700 (PDT) X-Gm-Message-State: AC+VfDxEtZFFAbLfLIvAhTu4J/bdwpGV/3gBYU9CObVF0O1bNyTmPY4a vqXGDHaSdidKE69SzDCTCa4DevByQYTdgu0/vB0= X-Google-Smtp-Source: ACHHUZ5eaXH+2ZAF4fHnYXBzRnFkA5YtnUXU4eQ/2jVQf1htEE9f/Mi7OoRz2npzP7jSz+nCIC3c1iaWCtyJpJyv3Tc= X-Received: by 2002:a2e:9d11:0:b0:2ae:cf05:5bae with SMTP id t17-20020a2e9d11000000b002aecf055baemr2139722lji.3.1685525051801; Wed, 31 May 2023 02:24:11 -0700 (PDT) MIME-Version: 1.0 References: <20230525143041.1172989-1-ardb@kernel.org> <20230525143041.1172989-6-ardb@kernel.org> In-Reply-To: From: "Ard Biesheuvel" Date: Wed, 31 May 2023 11:24:00 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [RFC PATCH 05/10] MdeModulePkg: Define memory attribute PPI To: "Ni, Ray" Cc: "devel@edk2.groups.io" , "Yao, Jiewen" , Gerd Hoffmann , Taylor Beebe , Oliver Smith-Denny , "Bi, Dandan" , "Gao, Liming" , "Kinney, Michael D" , Leif Lindholm , Sunil V L , "Warkentin, Andrei" Content-Type: text/plain; charset="UTF-8" On Wed, 31 May 2023 at 10:56, Ni, Ray wrote: > > > > > > 2. > > > > > When a memory region is marked from not-present to present, > > PageTableLib > > > > expects > > > > > caller to supply all memory attributes (including RW, NX, etc.) as the lib > > > > implementation doesn't > > > > > want to carry any default attributes.. > > > > > Do you think the MemoryAttribute PPI should expect the same to caller? > > > > > > > > > > > > > I'm not sure I follow. > > > > > > > > The PPI (as well as the UEFI protocol) can only operate on valid > > > > mapping, and can only be used to manipulate RP/RO/XP. It cannot be > > > > used to create mappings from scratch. > > > When a range of memory is marked as "RP", X86 page table clears the > > > "Present" bit for that range memory. > > > "Present" bit is a master bit in X86 page table. When that bit is clear, all > > > other bits ("Writable", "Non-Execution", etc.) are ignored by CPU. > > > > > > So, if caller clears the "RP" bit (setting "Present" bit in page table), that's an > > > operation to map back some memory. > > > X86 CpuPageTableLib requires all attributes be provided for mapping back > > > some memory. > > > > > > > > > > > Do you think this capability should be added? If so, I think it is > > > > reasonable to require the caller to provide all attributes, and on ARM > > > > this would have to include the memory cacheability type as we should > > > > not provide a default for that either. > > > > > > Yes. I think this is required. Having this rule can help caller write robust code > > > instead of depending on some default attributes in PPI/Protocol > > implementation. > > > > > > > I still don't follow. How does that work in the context of the > > attribute mask? Can you given some examples? > > OK. Let's reset the discussion. > For example, one caller's code as below: > // mark 0-4k as not-present > MemoryAttrributePpi->SetMemoryAttribute (0, 4K, RP, RP); // Use Attribute/Mask pattern to set RP > > Another caller's code: > // mark 0-4k as present > * MemoryAttributePpi->SetMemoryAttribute (0, 4K, 0, RP); // Use Attribute/Mask pattern to clear RP > OK, I see what you mean now. > Q1: Does the PPI support this usage? My current implementation for ARM does not support this, because the RP flag is not tied to the present bit but to the access flag. This means that setting and clearing RP will not create a valid region. > Q2: If it supports, what're the other attributes of 0-4k memory? Is XP set? Is RO set? > I am leaning towards not supporting this, at least initially, as updating permissions and creating mappings are two different things, and I am not convinced a generic PPI for creating mappings from scratch is needed at this point. This is a major difference between ARM and x86, as on x86, it is quite common to create mappings for regions that may have no memory at all. On ARM, this is not permited, and so we carefully create mappings only where we detect DRAM. However, I understand that it is not trivial to implement this restriction on x86, unless we remove RP from the set of attributes that this API can manipulate.