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.web08.17770.1646032097196586966 for ; Sun, 27 Feb 2022 23:08:17 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Nz7Ug9yB; 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=1646032095; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0p9i7g2GjSdSgIkiT1NokNqffbBPzPSuwiwmH6NjCcc=; b=Nz7Ug9yBuxuDtB+mhGYNC+kkOXhobvxfQXXk1Op45hGi3RIi+8E2yD2a5cUFlmFn9bSFnj z0SIeKDJlRyNe/zC/fDBr8hJNQekPjxjlJqi12Cti3kn1wnFcq8wevjRWuysQP62wQT/Qb QQIDTsnY35DzW12TGczYUlahdG5e0pk= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-77-ZDeOyGYZMlqaPGLTomhaPw-1; Mon, 28 Feb 2022 02:08:12 -0500 X-MC-Unique: ZDeOyGYZMlqaPGLTomhaPw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 289291006AA5; Mon, 28 Feb 2022 07:08:11 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.195.81]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AA422519B8; Mon, 28 Feb 2022 07:08:10 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id EC0781800393; Mon, 28 Feb 2022 08:08:08 +0100 (CET) Date: Mon, 28 Feb 2022 08:08:08 +0100 From: "Gerd Hoffmann" To: "Boeuf, Sebastien" Cc: "devel@edk2.groups.io" , "Yao, Jiewen" , "Justen, Jordan L" Subject: Re: [edk2-devel] [PATCH v4 4/7] OvmfPkg: Generate CloudHv as a PVH ELF binary Message-ID: <20220228070808.ao753pdtfupp3qs4@sirius.home.kraxel.org> References: <20220225130053.oizxc47lhvyr5cim@sirius.home.kraxel.org> <405b52b1df1cfb1989005334555e7163376877b2.camel@intel.com> MIME-Version: 1.0 In-Reply-To: <405b52b1df1cfb1989005334555e7163376877b2.camel@intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hi, > > Oh.  So the ELF header *replaces* the firmware volume header. > > Didn't notice that before. > > > > Hmm.  With that the varstore initialization most likely fails. > > There is a fallback path though, with ovmf storing variables > > elsewhere (in normal ram instead of firmware flash I think). > > Persistent variables don't work in that case. > > > > When the persistent varstore doesn't work anyway (and you are > > ok with that) you probably can drop the space reserved for it > > from the firmware image and use just a single page for the pvh > > elf header (and sharing VarStore.fdf doesn't make sense then). > > Sorry it's not entirely clear to me what should be done here. Should I > remove the VARS section since we're not using it anyway? > I'm lacking some knowledge here to understand what this is used for, > and how I actually broke it. I mean with the define and the include, I > ended up modifying exclusively the [FD.CLOUDHV] which is exactly what > was done for Xen. Do you think the Xen VARS section is broken as well? Probably. Not sure how xen uses the generated firmware images though. OVMF has three images. The OVMF_VARS.fd is the variable store. OVMF_CODE.fd is the firmware code. Both combined is OVMF.fd. The split into VARS and CODE exists to simplify firmware updates: On the host machine you'll have a per-guest VARS file with the persistent uefi variables, and the shared CODE file. Firmware upgrades work by simply updating the shared CODE file. The address space layout is the same in both cases (combined/splitted). The firmware takes 2M or 4M below 4G. The upper part is covered by the CODE, the lower part is covered by VARS. OVMF expects the varstore at a fixes address, but as mentioned can cope with the varstore not being there or not being backed by flash. So, do you use the CODE or VARS file for cloudhv? Does cloudhv emulate flash? take care, Gerd