On 31/01/19 10:37, Markus Armbruster wrote: >> >>> 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)? Non-SMM code cannot execute commands. This means two things: First, in addition to writes, there are nondestructive commands such as read device id. Those are also inaccessible to non-SMM if secure=on. Again, for non-SMM code it looks like your old ROM. This is not important but... ... CFI commands, even commands that are nondestructive or writes that fail because of readonly-ness, consist of multiple writes to the flash device. If non-SMM code could issue a partial command, the SMM flash driver would likely end up confused. Therefore it's probably a good idea to make all parallel flash devices have secure=on even if the content of the flash cannot be damaged, and that's why I never considered anything but -global to configure the property. Paolo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
