From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 501701A1EDF for ; Wed, 21 Sep 2016 04:36:34 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id n143so47116350ita.1 for ; Wed, 21 Sep 2016 04:36: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; bh=T7xTfNJ9KmH97BnY8+SAktWp8ACFwexGkF6+9XWs6gI=; b=bOUe93lVaGHYqiZc2chS0R59NKw+n+0Z9cNGjCS94YCMNbci7zuGI9B8rmrh3H43P2 iNJfkAS6/ECnHXMnt7tjnFxXgC3bvXdBGGFICCz/R8zuLYXl36cJHCb85HhAMVFKLlZr kpofJZlVx6DXNOK06QXn/M/Dmv8A0F4fDfnJc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T7xTfNJ9KmH97BnY8+SAktWp8ACFwexGkF6+9XWs6gI=; b=Uwu25IS1GmBHll7UjhANMpp8Ol5EBz6UdLnRLUWvmO4k1k9CUSoOAKkQJt875viMi5 bX4zGq0AOd5jc3EsG3EA3GWLoXSFULKT5nK+p67L23jywbnYKsYvMt2h1T2o/h2h1g0W qTLNYz0MXxDDzz0Ezd0zpTWsu240mahEqF2pMp6rIDzwld7WCx5oM5EWG94IYjNXv13n fZNH9IARYEUQZsNjIzijDYikb+9EDkNTJAVxNMgSNGoCvPvwKVFAQbd1byZG4/u7sEbh Af61+NK8aQ6yZnJOr+mg3N1c9lhkaZPZthmGTuDx4JbPOwyKFSjZ7HqR/IMFT8lXLvBJ CABg== X-Gm-Message-State: AE9vXwNrnGyhWkldzpQd16VT6ryT/+5l3URYlZkMvo36DaIusrcIZPg8Q5YiYsf/h7TDuprjLZbWgy6qj1eOdwS3 X-Received: by 10.36.71.73 with SMTP id t70mr3330998itb.47.1474457793735; Wed, 21 Sep 2016 04:36:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.204.195 with HTTP; Wed, 21 Sep 2016 04:36:33 -0700 (PDT) In-Reply-To: References: <4d4fe42c-0aeb-698b-9da5-63d8c215a160@redhat.com> From: Ard Biesheuvel Date: Wed, 21 Sep 2016 12:36:33 +0100 Message-ID: To: Bhupesh Sharma Cc: Laszlo Ersek , "edk2-devel@lists.01.org" , Sakar Arora Subject: Re: Exporting discontiguous System Memory to EFI STUB X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 11:36:34 -0000 Content-Type: text/plain; charset=UTF-8 On 21 September 2016 at 12:32, Bhupesh Sharma wrote: > Hi Ard, > >> From: Ard Biesheuvel >> Sent: Wednesday, September 21, 2016 4:50 PM >> [...] >> I recently fixed a problem in the MMU code where the maximum size of >> the VA range which is programmed into the MMU registers was based on >> the initial memory size, and adding memory (or MMIO) ranges later would >> cause problems. >> >> WIth the latest EDK2, adding memory may be done at any time, and will >> be reflected in the 1:1 mapping in the MMU > > Thanks. That looks promising. Can you please share the SHA-ID, commit-ID > of this *MMU fixup* patch. > commit dd82465a9f0f0beff0e4d74c6e3192b966853332 Author: Ard Biesheuvel Date: Fri Sep 9 09:01:56 2016 +0100 ArmPkg/ArmMmuLib: base page table VA size on GCD memory map size As reported by Eugene, the practice of sizing the address space in the virtual memory system based on the maximum address in the table passed to ArmConfigureMmu() is problematic, since it fails to take into account the fact that the GCD memory space may be extended at a later time, both for memory and for MMIO. So instead, choose the VA size identical to the GCD memory map size, which is based on PcdPrePiCpuMemorySize on ARM systems. Reported-by: Eugene Cohen Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel Reviewed-by: Eugene Cohen Reviewed-by: Leif Lindholm