From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 36839208F7903 for ; Mon, 18 Sep 2017 19:23:35 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id l136so5056415ita.0 for ; Mon, 18 Sep 2017 19:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SKBE5dwC8ypF18/DCvzmgOfc38g5teS20ufO/xkMJ7Y=; b=C9lEglqAsR2bSF3C3pxgIEIHKLSUmIpcnGvSRHpEy4Aw+GspF8yZY10gECjHxf7D55 TStipAme4O7ZYjoSzvoTEgl9KUZQ4UJt/DKGNpQVRBXFgFye4HGuX/rHaDmD8+XfPysn X1gS6/wtYU8plpGN2yMNKia7hJlwg0qS/ftbE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SKBE5dwC8ypF18/DCvzmgOfc38g5teS20ufO/xkMJ7Y=; b=OLFNEAbRRF3qMZNvMP2kUE65RaYzW5KPa3rlNmB2QS4Xu1khTWmjGwsv6G17ikBcId hmUn56KAFJBqNybQWPB8NxhBlijxH5KoIKEb44XdOGQtJVwNG+pbZxPoSjnjCDXsvyMM 9QV7WvnSjdx2N3Q5wb4nw2WqtJyh78Ps63RAYc4f0Q1ts0S0KpyQOx9JA1AEHvkd0lZn k1z9NwFvt0aOk8D0aTM9mZoFoSD6s6XGeHuGczroP0xB0frAZcScovmq6HSbnD3Q4kCp QFUtxcCejOBroMqGmPUlOvPdMLpkEaMaav9a3WnrNmj16wU6ioEIzV2tOnt+s62LNiyP z7rw== X-Gm-Message-State: AHPjjUjDt4mBydfEu+FuIMZY0fQmtxBMqfYDXP/YNEM5MoUkZv1okoLA fCt7hT9AkThV/NMrMZvJyQvGJ/P062dRPAfgFgFUWw== X-Google-Smtp-Source: AOwi7QDf6PvViufzoKjeGCyLX318+Nrzmc+9okSsH8O5K8LaJJ6ZfciRnYYHQYnfVMoFsvKUngj44Ojtn4cCHqaAa78= X-Received: by 10.36.40.13 with SMTP id h13mr302642ith.48.1505787998734; Mon, 18 Sep 2017 19:26:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.152.18 with HTTP; Mon, 18 Sep 2017 19:26:38 -0700 (PDT) In-Reply-To: <0C09AFA07DD0434D9E2A0C6AEB0483103B972DD1@shsmsx102.ccr.corp.intel.com> References: <0C09AFA07DD0434D9E2A0C6AEB0483103B972DD1@shsmsx102.ccr.corp.intel.com> From: Ard Biesheuvel Date: Mon, 18 Sep 2017 19:26:38 -0700 Message-ID: To: "Zeng, Star" Cc: Larry Cleeton , "edk2-devel@lists.01.org" , "Yao, Jiewen" Subject: Re: EFI_MEMORY_ATTRIBUTES_TABLE not in runtime memory X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 02:23:35 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 18 September 2017 at 18:52, Zeng, Star wrote: > As I know according to UEFI spec, it has no requirement about the Table n= eeds to be in runtime memory, but only requires the list (holding Guid valu= e and Table pointer) needs to be in runtime memory. > > "The InstallConfigurationTable() function is used to maintain the list of= configuration tables that are stored in the EFI System Table. The list is = stored as an array of (GUID, Pointer) pairs. The list must be allocated fro= m pool memory with PoolType set to EfiRuntimeServicesData." > > > Jiewen, you should know more detail about this feature. > Whether the list of configuration tables is in runtime memory and whether the tables themselves are in runtime memory are completely different things. Runtime memory will get a mapping in the virtual tables created by the OS, which is only necessary if the firmware itself refers to the contents when runtime services are in progress. Using runtime memory so that it will be automatically protected from allocation by the OS implies that the memory is lost even if the OS does not understand the table type in the first place. And if it does understand the table type, it can reserve the region itself. In summary, using runtime memory for configuration tables is a bad idea, and the fact that it is recommended for SMbios (and there is even a mention that no virtual mapping should be requested, which is impossible) is a mistake IMO. --=20 Ard.