> > > > With the help of fw_cfg, we can know the size of > > QemuFwCfgItemKernelSize/ > > QemuFwCfgItemInitrdSize/QemuFwCfgItemKernelSetupSize. > > That'll only work with direct kernel boot, when some boot loader > is in your boot workflow this will not work.
Indeed, the TDX startup library does things very differently from how we'd handle this for SEV-SNP. There are already 2 ranges of memory prevalidated in SEC that have to be specially skipped over in PEI. I tried the lazy accept changes from edk2-staging with SEV-SNP changes to prevalidate only the PEI installed memory https://github.com/AMDESE/ovmf/pull/4 and I just could not manage to get the guest to boot. It'd crash in the QemuTryBootKernel part of BDS. Tom Lendacky's suggestion for SEV-SNP is to pre-accept all memory under 4GB to make all that complexity go away. Only this approach worked in my own testing. With the MMIO hole it's just validating 3GB of memory. > > > > For guests which don't support lazy accept we could offer a > > > (runtime) option to simply accept all memory in ExitBootServices. > > What is the runtime option? Some new fw_cfg? > > Ideally without manual configuration (see also the reply in Dionna's thread). > > I think ovmf should start in lazy accept mode unconditionally. Accept > enough memory to reach dxe, but not more. Accept additional memory > needed on demand. This will probably be complicated for SEV-SNP. I couldn't get it to work as discussed above, but I wouldn't count myself a UEFI expert. > > Whenever we pass unaccepted memory to the guest os or not can be decided > rather late, I think we can wait with that until the first > BS->GetMemoryMap() call comes in. Doing it late gives is more options > to handle things automatically and it also simplifies SEC code. > > take care, > Gerd > -- -Dionna Glaze, PhD (she/her) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#90539): https://edk2.groups.io/g/devel/message/90539 Mute This Topic: https://groups.io/mt/91570202/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
