From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36728) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgFJ5-0006xl-Q5 for qemu-devel@nongnu.org; Thu, 09 Apr 2015 12:27:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YgFIy-0005M2-Qu for qemu-devel@nongnu.org; Thu, 09 Apr 2015 12:27:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53501) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgFIy-0005La-M1 for qemu-devel@nongnu.org; Thu, 09 Apr 2015 12:27:48 -0400 Message-ID: <5526A87E.3000407@redhat.com> Date: Thu, 09 Apr 2015 18:27:42 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1428582043-19080-1-git-send-email-pbonzini@redhat.com> <5526795F.1020802@redhat.com> <20150409135828.GO30629@toto> <5526901D.4000208@redhat.com> <5526A469.9060502@redhat.com> In-Reply-To: <5526A469.9060502@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH 0/3] pflash_cfi01: allow reading/writing it only in secure mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek , "Edgar E. Iglesias" Cc: Peter Maydell , Peter Crosthwaite , QEMU Developers , Gerd Hoffmann On 09/04/2015 18:10, Laszlo Ersek wrote: > In OVMF, the reset vector and the SEC phase code run from (read-only) > flash. SEC decompresses everything else to RAM. Also, SEC does not > access read-write flash (the varstore) at all. >=20 > The above is a specialty of OVMF. In ArmVirtualizationQemu (aka AAVMF), > two further module types run from flash, after SEC: PEI_CORE, and some > PEIMs (ie. the PEI phase comes into the picture). During PEI, read-only > access to the varstore should be supported. Read-only access should always be fine (though with a tweak to these patches, and slower---because it exits to QEMU---if another CPU is looking at the flash in MMIO mode). The problem is execution. But on x86 flash should never be accessed by multiple CPUs at the same time, unless all of them know that the flash is in ROM mode. As I understand it, on ARM secure (EL3) and non-secure (EL<3) modes have effectively different address spaces. Therefore, one EL3 CPU could put the flash in MMIO mode for programming, while another EL1 CPU could be reading from the flash in ROM mode. In QEMU, this could be implemented with two memory regions and per-CPU address spaces. These patches should not get in the way, but they would not be useful. Thanks, Paolo > ... I'm providing the above as "standalone facts", neither as > confirmation nor as disproof for what you wrote. I don't know enough to > combine these edk2 bits with what you wrote myself, but my hope is that > *you* can maybe combine them, if I point them out. :)