On 08/27/14 18:58, Ard Biesheuvel wrote: > The ARM Versatile Express development hardware is set up like this, > that is the whole and only reason. > I guess we could change it if there is a strong reason to do so, but > parity with the other emulated machines makes the maintenance job a > bit easier, I imagine. > Both the size and the block size are fixed, currently.
Thanks for enlightening me. Just stick with it then, I'd say. > Considering this is all emulated anyway, is there a performance > penalty we should taken into account when using such a relatively > large block size? It depends on the NOR flash driver (the driver that produces the FirmwareVolumeBlockProtocol, or FirmwareVolumeBlock2Protocol). The FVB (and FVB2) protocols expose a block-centric view of the flash. The performance (when running on QEMU/KVM) largely depends on the CFI command that the driver uses to reprogram or erase the flash. If those commands are block level, then you trap once per block (I think anyway). If you use byte-level programming, then you trap once per byte (this I know for sure). During FTW reclaim, the whole live and spare areas are rewritten several times. OVMF's flash driver currently uses byte-level CFI commands -- and I have a *very* distant plan to update that to block level, given that the FVB(2) interface is block-level anyway --, and therefore the reclaim is *somewhat* noticeable on x86_64 KVM. You get like 100% system load from the VCPU (the virtual BP) that is running edk2, for 1 or 2 seconds. (Reclaim happens very rarely.) Individual non-volatile variable writes are unnoticeable. Given that OVMF's live area is 56K, and its spare area is 64K (and the block size is only 4K), you could see more serious CPU demand with a block size of 256KB. It probably doesn't matter with TCG (which is slow anyway), but it could be noticeable with KVM. This is pure speculation of course. Also, we could actually check out the FVB(2) driver in question, "ArmPlatformPkg/Drivers/NorFlashDxe": FvbWrite() [NorFlashFvbDxe.c] NorFlashWriteSingleBlock() [NorFlashDxe.c] It seems to have a trick for writes <= 128 bytes (operating with 4-byte words --> NorFlashWriteSingleWord()), and for larger writes, it seems to call NorFlashWriteBlocks() --> NorFlashWriteFullBlock(). NorFlashWriteFullBlock() says // To speed up the programming operation, NOR Flash is programmed using the Buffered Programming method. ... I guess you shouldn't see delays even on KVM; the driver appears performance-conscious. There's probably nothing to do until you can notice and measure any tight loops. > >>> [PcdsDynamicDefault.common] >>> # System Memory -- 1 MB initially, actual size will be fetched from DT >>> gArmTokenSpaceGuid.PcdSystemMemoryBase|0x40000000 >>> @@ -179,7 +189,7 @@ >>> MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf >>> MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf >>> MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf >>> - MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe.inf >>> + MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf >> >> I'll mention in passing that >> "MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf" is >> good for a non-authenticated variable store only, ie. no secure boot >> support. For secure boot support, CryptoPkg / OpensslLib would be >> necessary too, and another variable driver from under SecurityPkg, etc >> etc etc, but for this series, the patch definitely suffices. >> > > Yes, I am aware of that. I implemented Secure Boot for the Foundation > model and VExpress-A15 here: > https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/linaro-topic-authenticated-boot Awesome! > I intend to port those changes onto this platform, which will make my > remaining work regarding secure boot a lot easier. > (The ARM semihosting interface does not support listing directories > only opening files directly, which doesn't work with mokmanager/shim) Right. With qemu you can use the vvfat block protocol driver for easy semihosting, such as: -drive file=fat:/host/directory/name,id=drive0,if=none,format=raw \ -device virtio-blk-device,drive=drive0 It can expose a host directory as a FAT16 volume (up to "516.06 MB" in size), which should be enough for keys that you want to enrol etc. Alternatively, guestfish (from libguestfs fame) is very good at quickly modifying offline virtual disk images. Thanks, Laszlo ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
