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::d44; helo=mail-io1-xd44.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (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 D79252116747A for ; Thu, 18 Oct 2018 22:28:34 -0700 (PDT) Received: by mail-io1-xd44.google.com with SMTP id z16-v6so22391889iol.6 for ; Thu, 18 Oct 2018 22:28:34 -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=T84xHZ0s+EtBsokQ6heY4w5IUtNbTddKCb4BdwaDxPo=; b=PQGHN9ZOHYgojwGJ7AzMG2hxo+X0Mch9lLYB4Cciv6/Bpp6GSqiufoyIyBAajY0q2v E5KzgqznyK4I1Wb2LltiEvBLa8Jl+8euiG+g4ZS5bLQG0L4ShzBnvIVMPIwym1w29HdY DRFhzVU2hjXe9IXbT0Z8q4yJMlSJBCeQq4E/E= 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=T84xHZ0s+EtBsokQ6heY4w5IUtNbTddKCb4BdwaDxPo=; b=qQ1wWsAvd57jICMJ92/pSHRwdcodozRSuSBnLePOR4yvQdacgi+M8t4rnbZb2MiPQ+ mu0QvmUFhxX/md5hoEM+QHJJZXL8iIYyYRDOhY4HLrrhl43QasJVMVEm27difw/dnNNo DgDNxtOYEg99jfukMiqc0nhLHWvHEHw9q4hx0PCp3XS+pz+RXd1LPuLelaUoIsHTdjv2 /mJBWQL+pVqXoJ3cAy/Hc/i5CxUe+CqnfQ1qR1aq+ib/+uj3m7j1u2iFKzy4gx17SpsL nfAdBVZEuY27r175mziXtAfRUOPe/WREiivPsIgde5G4rXIgSYjNyXZkx4AhaeeKISuX AeMA== X-Gm-Message-State: AGRZ1gJjf2+wsxqxr9iL2bm5t3Fk+OvRk9qCc7tuAP1o8IdYtHk/kl7n A4NLRHUZAcyqh+fy45ZOy2MIvbSIblHezKgABquRBJDM X-Google-Smtp-Source: AJdET5e1uyp+Lv9mZKILDpOhyxuMpxnimV1em+yAMtBQNO0f4lpa/jOpHDl2Ld3LfW6ROQgUvrxmGLF2FqSh0f3Gac4= X-Received: by 2002:a6b:5d12:: with SMTP id r18-v6mr1992120iob.170.1539926913899; Thu, 18 Oct 2018 22:28:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:5910:0:0:0:0:0 with HTTP; Thu, 18 Oct 2018 22:28:33 -0700 (PDT) In-Reply-To: <0C09AFA07DD0434D9E2A0C6AEB0483103BC23615@shsmsx102.ccr.corp.intel.com> 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> <0C09AFA07DD0434D9E2A0C6AEB0483103BC23615@shsmsx102.ccr.corp.intel.com> From: Ard Biesheuvel Date: Fri, 19 Oct 2018 13:28:33 +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:28:35 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 19 October 2018 at 13:25, Zeng, Star wrote: > Be honest, I am not clear about the history why EfiBootServicesData is re= quired for ESRT. But OS indeed cares about ESRT table, for example, I guess= the Firmware in Device Manager for Windows is built based on ESRT table. I= n fact, I think OS loader can access either EfiBootServicesData or EfiRunt= imeServicesData configuration table as it controls the runtime phase point. > The problem is not with the OS. The OS can access it it any time it want, and create a virtual mapping for it. The problem is with the firmware: any table that the firmware wants to access *itself* requires a virtual mapping to be provided by the OS in SetVirtualAdressMap(), so that the virtual address is known to the firmware. > I am concerning that even the spec could be updated, our code may still n= eed caching for backward compatibility. > I don't think that should be a problem: Linux permits the ESRT to reside in EfiRuntimeServicesData already, because certain x86 production systems do that. This means that it is highly unlikely that Windows disallows this. > > -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > Sent: Friday, October 19, 2018 1:11 PM > To: Zeng, Star > Cc: Peter Jones ; edk2-devel@lists.01.org; Dong, Eric = ; Leif Lindholm ; Kinney, Mi= chael D ; Yao, Jiewen > Subject: Re: [PATCH] MdeModulePkg/EsrtDxe: allocate ESRT table from RtSer= vicesData memory > > On 19 October 2018 at 13:01, Ard Biesheuvel w= rote: >> 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 notificatio= n(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 ESR= T 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 EfiRunt= imeServicesData anyway [so that the firmware itself can access it], is ther= e still a point to keeping this requirement? > Shouldn't we update the spec regardless?