From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web10.1976.1655280314149162100 for ; Wed, 15 Jun 2022 01:05:14 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=HStmk2jG; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1655280313; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=lQ+lGw1FQTL/twW2C2REW9Ktug8A+r56Xzc7VZc8/qA=; b=HStmk2jGUzXkx/Zj1Q3aY9bdAXuqU3Xznc3nJtnS4/0Xus9gAf9L+mg1grSmwDebz0IohK 2MTNOTTTxCGAK93ZlrSXvbCadFRsy/Dq7o43MWNkoIaARdJolDz8dBc1KDwysRShXKbmvw Y/d7a+0tuo7Uah7YdVqb4W8esZQwz3U= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-333-QjBADFbwPZi046pxtUgXjA-1; Wed, 15 Jun 2022 04:05:10 -0400 X-MC-Unique: QjBADFbwPZi046pxtUgXjA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 92F4183397A; Wed, 15 Jun 2022 08:05:09 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.40]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5B9671121314; Wed, 15 Jun 2022 08:05:09 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 22F681800081; Wed, 15 Jun 2022 10:05:08 +0200 (CEST) Date: Wed, 15 Jun 2022 10:05:08 +0200 From: "Gerd Hoffmann" To: "Xu, Min M" Cc: "devel@edk2.groups.io" , "Aktas, Erdem" , James Bottomley , "Yao, Jiewen" , Tom Lendacky , Dionna Glaze Subject: Re: [PATCH 07/14] OvmfPkg: Add PCD and DEFINEs for Lazy Accept page. Message-ID: <20220615080508.oqjojsevfxc4pw3f@sirius.home.kraxel.org> References: <20220607104550.hz6c7etgxtksylwu@sirius.home.kraxel.org> <20220608061805.vvsjiqt55rqnl3fw@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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