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.
Paolo
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
