On 02/28/20 05:04, Andrew Fish wrote: > Maybe I was overcomplicating this. Given your explanation I think the part > I'm missing is OVMF is implying FLASH layout, in this split model, based on > the size of the OVMF_CODE.fd and OVMF_VARS.fd. Given that if OVMF_CODE.fd > gets bigger the variable address changes from a QEMU point of view. So > basically it is the QEMU API that is making assumptions about the relative > layout of the FD in the split model that makes a migration to larger ROM not > work.
No, QEMU does not make any assumptions here. QEMU simply grabs both pflash chips (the order is not random, it can be specified on the command line -- in fact the QEMU user is expected to specify in the right order), and then QEMU maps them in decreasing address order from 4GB in guest-phys address space. If we enlarge OVMF_CODE.fd, then the base address of the varstore (PcdOvmfFlashNvStorageVariableBase) will sink. That's not a problem per se, because QEMU doesn't know about PcdOvmfFlashNvStorageVariableBase at all. QEMU will simply map the varstore, automatically, where the enlarged OVMF_CODE.fd will look for it. > Basically the -pflash API does not support changing the size of the ROM > without moving NVRAM given the way it is currently defined. Let me put it like this: the NVRAM gets moved by virtue of how OVMF is built, and by how QEMU maps the pflash chips into guest-phys address space. They are in sync, automatically. The problem is when the NVRAM is internally restructured, or resized -- the new OVMF_CODE.fd binary will reflect this with changed PCDs, and look for "stuff" at those addresses. But if you still try to use an old (differently sized, or differently structured) varstore file, while QEMU will happily map it, parts of the NVRAM will just not end up in places where OVMF_CODE.fd expects them. > > Given the above it seems like the 2 options are: > 1) Pad OVMF_CODE.fd to be very large so there is room to grow. There's already room to grow, *inside* OVMF_CODE.fd. As I've shown elsewhere in this thread, even the 2MB build has approx. 457 KB free in the DXEFV volume, even without link-time optimization and without DEBUG/ASSERT stripping, if you don't enable additional features. > 2) Add some feature to QUEM that allows the variable store address to not be > based on OVMF_CODE.fd size. Yes, this has been proposed over time. It wouldn't help with the case when you change the internal structure of the NVRAM, and try to run an incompatible OVMF_CODE.fd against that. > I did see this [1] and combined with your email I either understand, or I'm > still confused? :) > > I'm not saying we need to change anything, I'm just trying to make sure I > understand how OVMF and QEMU are tied to together. I think the most interesting function for you could be pc_system_flash_map(), in "hw/i386/pc_sysfw.c", in the QEMU source. > > [1] https://www.redhat.com/archives/libvir-list/2019-January/msg01031.html Thanks Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#55086): https://edk2.groups.io/g/devel/message/55086 Mute This Topic: https://groups.io/mt/71141681/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
