qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 0/3] pflash_cfi01: allow reading/writing it


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC PATCH 0/3] pflash_cfi01: allow reading/writing it only in secure mode
Date: Thu, 09 Apr 2015 18:27:42 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0


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.
> 
> 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. :)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]