On Tue, Sep 06, 2022 at 06:02:00PM +0530, Sunil V L wrote: > Hi Gerd, > > On Tue, Sep 06, 2022 at 12:41:28PM +0200, Gerd Hoffmann wrote: > > Hi, > > > > > 3)Make the EDK2 image size to match with what qemu flash expects > > > truncate -s 32M Build/RiscVVirt/DEBUG_GCC5/FV/RISCV_VIRT.fd > > > > Hmm, we have that kind of padding on arm too (64M for code and 64M for > > vars) and only a fraction of the space is actually used, which isn't > > exactly ideal. So not sure it is a good plan to repeat that on riscv. > > Yeah.. but it looks like limitation from qemu flash emulation. Do you mean > this limitation exists for arm in general on real flash also?
Well, at least on x86 flash devices can have odd sizes. I don't think the qemu pflash emulation dictates anything here. I think the underlying problem we actually have in qemu is that the flash size indirectly dictates the memory layout. We pack the flash devices next to each other, on x86 downwards from 4G, on arm upwards from zero, not sure what risc-v is dong here. edk2 arm code expects the variable store being mapped at 64m. So QEMU_EFI.fd (which is actually 2M in size) gets padded to 64m, which has the desired effect that the next flash device (the varstore) is mapped at 64m. But also has the side effect that we map 62m of zeros into the guest address space ... The vars file is padded to 64m for consistency with the code. Not padding the vars file should have no bad side effects I think, except for live migration where the flash size change might cause compatibility problems. Not padding the code file needs some alternative way to specify the memory layout, to make sure the vars flash continues to be mapped at 64m even when the code flash is smaller. Cc'ed Pawel who investigates that right now. One possible option is to just hard-code the flash memory layout per machine type or per architecture. Another option would be to add some way to configure that on the command line. take care, Gerd
