[Top][All Lists]

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

Re: [Qemu-block] [Qemu-devel] Configuring pflash devices for OVMF firmwa

From: Markus Armbruster
Subject: Re: [Qemu-block] [Qemu-devel] Configuring pflash devices for OVMF firmware
Date: Thu, 31 Jan 2019 10:37:58 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Paolo Bonzini <address@hidden> writes:

> On 31/01/19 09:33, Markus Armbruster wrote:
>> I thought secure=on affected only writes (and so wouldn't matter with
>> readonly=on), but I was wrong:
>>     static MemTxResult pflash_mem_read_with_attrs(void *opaque, hwaddr addr, 
>> uint64_t *value,
>>                                                   unsigned len, MemTxAttrs 
>> attrs)
>>     {
>>         pflash_t *pfl = opaque;
>>         bool be = !!(pfl->features & (1 << PFLASH_BE));
>>         if ((pfl->features & (1 << PFLASH_SECURE)) && !attrs.secure) {
>>             *value = pflash_data_read(opaque, addr, len, be);
>>         } else {
>>             *value = pflash_read(opaque, addr, len, be);
>>         }
>>         return MEMTX_OK;
>>     }
>> pflash_data_read() is what pflash_read() does when pfl->cmd is 0.
> Reads from flash actually do not go through here; this function executes
> if the flash chip is already in MMIO mode, which happens after you
> *write* a command to the memory area.  With secure=on, you just cannot
> do a command write unless you're in SMM, in other words the flash chip
> can only ever go in MMIO mode if you're in SMM.
>> Hmm, why is it okay to treat all pfl->cmd values the same when
>> secure=on?
> But doesn't matter.  You just don't want MMIO mode to be active outside
> SMM: all that non-SMM code want to do with the flash is read and execute
> it, as far as they're concerned it's just ROM and the command mode is
> nonexistent.

Out of curiosity: what effect does secure=on have when the device is
read-only (pflash_t member ro non-zero)?

reply via email to

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