Hi, > > Where does the 512MB figure come from?
> 512MB is an experiment value. It includes the minimum DXE memories > (~96MB) and the memories to load a normal kernel-image/initrd. In our > internal test, 512MB can satisfy most of the usage scenarios without > accepting more memories later. And it has no serious performance > impact. Yes, it'll most likely work for > 90% of the use cases. The remaining cases will come some day though, so having a plan for that would be good IMHO. > > Using a fixed amount of memory doesn't look very robust to me. Is it > > possible to accept memory when the guest calls ExitBootServices? That way > > we could guarantee a minimum amount of *free* accepted memory being > > available, to make sure the linux kernel has enough memory to decompress > > itself, allocate memory management data structures and get its own lazy > > accept support going. > 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. > > 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. 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 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#90530): https://edk2.groups.io/g/devel/message/90530 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] -=-=-=-=-=-=-=-=-=-=-=-
