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::144; helo=mail-it1-x144.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it1-x144.google.com (mail-it1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) (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 C76B6211648BB for ; Mon, 19 Nov 2018 11:27:33 -0800 (PST) Received: by mail-it1-x144.google.com with SMTP id a205-v6so10050802itd.4 for ; Mon, 19 Nov 2018 11:27:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yaRQqlYjViXJYGHqChCOmSLvQgT1PslBVzwwB5eMNP8=; b=InuHP9EpUFJuk4WAy9HxklhW0oeZ5PLUoQ5CYBwCHkBK8MS2FuPAmmd9vN/EUWYyjO n2tDpdEMbqhTzG5/pj8Swdks9vpUY9bfPsPV93OiRpy2PZE1WeD/KOZrQNxNbuTwuDdq a5VpVYc8jy82BG0Ew/UAXgapiEl6fHgF/Ojrs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yaRQqlYjViXJYGHqChCOmSLvQgT1PslBVzwwB5eMNP8=; b=iFny0GF4H6ug9MUECk3qjrLFFGbhiIL1/AyYPfBvJ0hvDOt21rjb2T8xrPb4Kc5MF6 nUhMyZzcPEIK8fP2K8Sx1gbHs11bT7k6yRy7YsONVr7a80V5WXD+yV+jfL+QVK0oLFN+ OPeZW1nF5WYAcG7Af4JQLmy3N5yBrpzWZ0arJ6XcWXYRYNQoHAT01OFsr1dv4+aSNoO0 Fp3bA+c+paQSnTt5FgFGCMhxvtACmUL+PlXxda39ff85nHL99su3tCuTWJZ1S5u8d3P0 wc7XARW5T/REK9zp8Ns7lhCVt7h6UWzk3qZmjtkItwDxk7prDuGV1RsRF4PSwagaNnVT LTCw== X-Gm-Message-State: AGRZ1gLK10dIJ2Eqle1EWQO9ITO8IIKWnd4kiBmnGsrgXi/hNSRPhC66 aq7YoA8hynu/7SHdKC+YHE0oIG6rFkXtlluhbGDa7A== X-Google-Smtp-Source: AFSGD/XpneSc+bMoLReYoe70fPHCao10nMzW4uIthCFJqbio24djkXy/3+CrlmbZ39YNbz0/HCT4kp1q9YhUSANOcMA= X-Received: by 2002:a05:660c:4b:: with SMTP id p11mr2438353itk.71.1542655653028; Mon, 19 Nov 2018 11:27:33 -0800 (PST) MIME-Version: 1.0 References: <20181117004524.31851-1-ard.biesheuvel@linaro.org> <20181117004524.31851-3-ard.biesheuvel@linaro.org> <20181119191044.4uqakfz5dfmxdctz@bivouac.eciton.net> <20181119192456.67cvm64mhvqyyquc@bivouac.eciton.net> In-Reply-To: <20181119192456.67cvm64mhvqyyquc@bivouac.eciton.net> From: Ard Biesheuvel Date: Mon, 19 Nov 2018 11:27:22 -0800 Message-ID: To: Leif Lindholm Cc: "edk2-devel@lists.01.org" , Laszlo Ersek , =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= , Hongbo Zhang Subject: Re: [PATCH 2/2] ArmVirtPkg/NorFlashQemuLib: discover NOR flash banks dynamically 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: Mon, 19 Nov 2018 19:27:34 -0000 Content-Type: text/plain; charset="UTF-8" On Mon, 19 Nov 2018 at 11:24, Leif Lindholm wrote: > > > On Mon, Nov 19, 2018 at 11:16:09AM -0800, Ard Biesheuvel wrote: > > On Mon, 19 Nov 2018 at 11:10, Leif Lindholm wrote: > > > > > > On Fri, Nov 16, 2018 at 05:29:05PM -0800, Ard Biesheuvel wrote: > > > > On Fri, 16 Nov 2018 at 16:45, Ard Biesheuvel wrote: > > > > > > > > > > NorFlashQemuLib is one of the last remaining drivers in ArmVirtPkg > > > > > that are not based on the device tree received from QEMU. > > > > > > > > > > For ArmVirtQemu, this does not really matter, given that the NOR > > > > > flash banks are always the same: the PEI code is linked to execute > > > > > in place from flash bank #0, and the fixed varstore PCDs refer to > > > > > flash bank #1 directly. > > > > > > > > > > However, ArmVirtQemuKernel can execute at any offset, and flash bank > > > > > > > > #0 is configured as secure-only when running with support for EL3 enabled. > > > > > > Never gets old :) > > > > No this is entirely reasonable: it makes perfect sense for a NOR flash > > at address 0x0 to be secure only on a system that implements EL3, > > since mach-virt's default reset vector is 0x0. > > *cough* sorry, I was referring to the leading #. > Ah yes :-) Been caught by that a couple of times already. > > > > > In this case, NorFlashQemuLib should not expose the first flash bank > > > > > at all. > > > > > > > > > > To prevent introducing too much internal knowledge about which flash > > > > > bank is accessible under which circumstances, let's switch to using > > > > > the DTB to decide which flash banks to expose to the NOR flash driver. > > > > > > Does this mean we as a side effect get rid of the limitation that the > > > pflash image needs to be exactly 64MB. Or does that require further > > > changes on the QEMU side? > > > > No that is a QEMU thing. > > OK, thanks for confirming. > But this should mean that we don't need any changes on the guest sides > if/when we do fix this in QEMU? > This would indeed get rid of any discrepancies between what QEMU exposes and what the firmware assumes, so yes, it's an improvement in that sense. However, I don't think the QEMU side of this is likely to change any time soon.