Re: [libvirt] [Qemu-devel] Configuring pflash devices for OVMF firmware

Paolo Bonzini <pbonzini(a)redhat.com&gt; 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)?