Comment 9 for bug 1885662

@Stéphane: I suspect you can just look at the size of the VARS file itself. 2MB VARS files are 256K. 4MB ones are (...does test build...) 528K. I believe these file sizes are static, but would be good to verify.

Bumping from 2MB->4MB apparently bumps our Non-volatile variable storage from 56KB to 256KB:
 https://github.com/tianocore/edk2/blob/master/OvmfPkg/README#L350
If we're already surpassing 56KB, is bumping to just 256KB short sighted? 4MB/256KB seems to be the max upstream supports at the moment, so we likely don't have any other option.

fyi, it looks like ARM/AARCH64 have 256K VarStores already:
$ grep Size: edk2-2020.05/ArmVirtPkg/VarStore.fdf.inc
  # Size: 0x40000 (gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize) -

Is there descriptor (debian/descriptors/*.json) syntax for exposing the supported variable size? I don't see anything in QEMU's descriptors in master, which I believe are canonical. I suppose we can just point 40-edk2-x86_64-secure-enrolled.json and 50-edk2-x86_64-secure.json to the larger images and no longer provide descriptors that point at the 2MB images. That's the best way I can think of to prioritize 4MB over 2MB - and should work for libvirt and things built on top of it like OpenStack.

Are we coordinating with other vendors on this? Would obviously be nice to do things consistently.