From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4864:20::143; helo=mail-it1-x143.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it1-x143.google.com (mail-it1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 6A78221167473 for ; Thu, 18 Oct 2018 22:11:21 -0700 (PDT) Received: by mail-it1-x143.google.com with SMTP id c85-v6so3199363itd.1 for ; Thu, 18 Oct 2018 22:11:21 -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; bh=/krDw8BELt2fZrl56Rp6bbvzKahu6jhVb57np0GlyWk=; b=CJ4vlFnKfW74ag1cGhI7V8RctyI6xbluGXj0GM7fbA6P0xQEchCtX+cQbZ+rjxS5Sx 9RKnz8cIINOPzmpYFjOuz4BGUWtUZSoRQZheowIcMXK3T+NdI5bK7nUCHB8TpGw0Un1Z Kmfgfmg93tHGi/rW3wELPjmEcJY1sAV5qSygM= 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; bh=/krDw8BELt2fZrl56Rp6bbvzKahu6jhVb57np0GlyWk=; b=L0SYfBn0VtI/ZWMda1JkYFwao9aAm23nqxGdPNVaESgwvguHXnnd/GwsA2dAW/9tAX Bu4A9GULbqyNLRg9O23Giw1ST1Rk+rDPfID4tU+e6WqU6oFN4xPu0XMKWSB6/HaF87AX S10RHD3aglS1dCQPuSkedCFY1N1pkH4wmjqHcwBDlgHPUQdBNyS6+nMsdne8v2XzvbTI bmT/S9M0dAZxInJ9cHrnb87CWMAiM31iLsno+DkS/RIYh25ZSXoAWM1EAm0+Faj7EhC6 WLjwKXh7slEcQTaUXTZXsNrGZqw/jJg413Y8H9Q7dP3uR+2u4UI3mIIB0P0iHRJ3UhwF ChQQ== X-Gm-Message-State: ABuFfogVyH2WR9NgyIv8ZAKfyi4CTXTuEE4gOVEhiYyLV70lPdZKyPyX B8DGJsnpi8mCPdQN90vN1g25DTwAosqrQOV96PxL5Ic3 X-Google-Smtp-Source: ACcGV62egsbNLJWK6OQ868kS0q5u6fDcAv3/qccH7E/+rTkxBG+O1SooYLf4v1MQ6jzyDiMNLsMfkJDsZj+XSLCdjkA= X-Received: by 2002:a24:4ac5:: with SMTP id k188-v6mr2467073itb.158.1539925881249; Thu, 18 Oct 2018 22:11:21 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:5910:0:0:0:0:0 with HTTP; Thu, 18 Oct 2018 22:11:20 -0700 (PDT) In-Reply-To: References: <20181019025418.3037-1-ard.biesheuvel@linaro.org> <0C09AFA07DD0434D9E2A0C6AEB0483103BC2352B@shsmsx102.ccr.corp.intel.com> <0C09AFA07DD0434D9E2A0C6AEB0483103BC2357A@shsmsx102.ccr.corp.intel.com> <0C09AFA07DD0434D9E2A0C6AEB0483103BC235A6@shsmsx102.ccr.corp.intel.com> From: Ard Biesheuvel Date: Fri, 19 Oct 2018 13:11:20 +0800 Message-ID: To: "Zeng, Star" Cc: Peter Jones , "edk2-devel@lists.01.org" , "Dong, Eric" , Leif Lindholm , "Kinney, Michael D" , "Yao, Jiewen" Subject: Re: [PATCH] MdeModulePkg/EsrtDxe: allocate ESRT table from RtServicesData memory X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 05:11:22 -0000 Content-Type: text/plain; charset="UTF-8" On 19 October 2018 at 13:01, Ard Biesheuvel wrote: > On 19 October 2018 at 12:48, Zeng, Star wrote: >> Ok, thanks and got the case. >> >> DxeCapsuleLibVirtualAddressChangeEvent may be too late as it could not allocate pool to do caching. >> I meant registering gEfiSystemResourceTableGuid event group notification(installconfigurationtable will trigger event group) and do caching in the notification function. >> >> > > OK, I will create a bugzilla for this. > As I understand it, the reason we require EfiBootServicesData for the ESRT is because the OS may not care about this table, and so we don't want to waste the memory. However, if we end up caching the entire table in EfiRuntimeServicesData anyway [so that the firmware itself can access it], is there still a point to keeping this requirement? Shouldn't we update the spec regardless?